Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #63381 > unrolled thread

Re: the Gravity of Python 2

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-07 11:19 +1100
    Re: the Gravity of Python 2 Martijn Faassen <faassen@startifact.com> - 2014-01-07 13:54 +0100
      Re: the Gravity of Python 2 Martijn Faassen <faassen@startifact.com> - 2014-01-07 17:07 +0100
        Re: the Gravity of Python 2 Martijn Faassen <faassen@startifact.com> - 2014-01-07 17:42 +0100
          Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-08 04:00 +1100
            Re: the Gravity of Python 2 Martijn Faassen <faassen@startifact.com> - 2014-01-08 13:36 +0100
              Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-08 23:46 +1100
                Re: the Gravity of Python 2 Martijn Faassen <faassen@startifact.com> - 2014-01-08 16:08 +0100
              Re: the Gravity of Python 2 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-09 00:01 +1100
                Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-08 14:08 +0000
                Re: the Gravity of Python 2 Martijn Faassen <faassen@startifact.com> - 2014-01-08 16:22 +0100
                  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 02:39 +1100
                  Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-08 15:50 +0000
                  Re: the Gravity of Python 2 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-09 08:55 +1100
              Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-08 09:15 -0500
                Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-08 14:30 +0000
                  Re: the Gravity of Python 2 Martijn Faassen <faassen@startifact.com> - 2014-01-08 16:26 +0100
                  Re: the Gravity of Python 2 Kevin Walzer <kw@codebykevin.com> - 2014-01-08 18:42 -0500
                    Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-08 20:27 -0500
                      Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 12:47 +1100
                        Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-08 21:25 -0500
                          Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 14:17 +1100
                            Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-08 22:35 -0500
                              Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 15:03 +1100
                                Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-08 23:29 -0500
                                  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 15:34 +1100
                                  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 15:38 +1100
                                  Re: the Gravity of Python 2 Ethan Furman <ethan@stoneleaf.us> - 2014-01-08 21:31 -0800
                                  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 17:34 +1100
                                  Re: the Gravity of Python 2 Ben Finney <ben+python@benfinney.id.au> - 2014-01-09 17:57 +1100
                                  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 18:56 +1100
                                    Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-09 09:14 -0500
                                      Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-10 01:57 +1100
                                        Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-09 08:21 -0800
                                          Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 16:30 +0000
                                            Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-09 09:07 -0800
                                              Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 18:20 +0000
                                              Re: the Gravity of Python 2 Ethan Furman <ethan@stoneleaf.us> - 2014-01-09 10:29 -0800
                                          Re: the Gravity of Python 2 Tim Golden <mail@timgolden.me.uk> - 2014-01-09 16:41 +0000
                                          RE: the Gravity of Python 2 Nick Cash <nick.cash@npcinternational.com> - 2014-01-09 16:42 +0000
                                          Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 16:50 +0000
                                          Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-10 07:35 +1100
                                            Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-09 12:54 -0800
                                              Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-10 08:12 +1100
                                      Re: the Gravity of Python 2 Dan Sommers <dan@tombstonezero.net> - 2014-01-09 15:01 +0000
                                        Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-10 02:17 +1100
                                      Re: the Gravity of Python 2 Ethan Furman <ethan@stoneleaf.us> - 2014-01-09 07:56 -0800
                                  Re: the Gravity of Python 2 Kushal Kumaran <kushal.kumaran@gmail.com> - 2014-01-09 11:36 +0530
                                  Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 08:53 +0000
                                  Re: the Gravity of Python 2 Ben Finney <ben+python@benfinney.id.au> - 2014-01-09 20:03 +1100
                                  Re: the Gravity of Python 2 Kushal Kumaran <kushal.kumaran@gmail.com> - 2014-01-09 14:51 +0530
                                    Re: the Gravity of Python 2 Piet van Oostrum <piet@vanoostrum.org> - 2014-01-09 12:26 +0100
                                  Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 09:51 +0000
                                  Re: the Gravity of Python 2 Ben Finney <ben+python@benfinney.id.au> - 2014-01-10 00:35 +1100
                                    Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-09 09:32 -0500
                          Re: the Gravity of Python 2 Ben Finney <ben+python@benfinney.id.au> - 2014-01-09 14:34 +1100
                            Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-08 22:44 -0500
                          Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 14:42 +1100
                            Re: the Gravity of Python 2 Piet van Oostrum <piet@vanoostrum.org> - 2014-01-09 15:06 +0100
                              Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-10 01:34 +1100
                                Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-09 09:44 -0500
                                Re: the Gravity of Python 2 Piet van Oostrum <piet@vanoostrum.org> - 2014-01-09 17:51 +0100
                                  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-10 07:43 +1100
                          Time zones and why they change so damned often (was: the Gravity of Python 2) Ben Finney <ben+python@benfinney.id.au> - 2014-01-09 14:54 +1100
                          Re: Time zones and why they change so damned often (was: the Gravity of Python 2) Chris Angelico <rosuav@gmail.com> - 2014-01-09 15:14 +1100
                            Re: Time zones and why they change so damned often (was: the Gravity of Python 2) Peter Pearson <ppearson@nowhere.invalid> - 2014-01-10 18:22 +0000
                              Re: Time zones and why they change so damned often MRAB <python@mrabarnett.plus.com> - 2014-01-10 18:48 +0000
                              Re: Time zones and why they change so damned often Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-10 18:53 +0000
                                Re: Time zones and why they change so damned often Grant Edwards <invalid@invalid.invalid> - 2014-01-10 19:55 +0000
                                  Re: Time zones and why they change so damned often Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-01-10 19:45 -0500
                                  Re: Time zones and why they change so damned often Gene Heskett <gheskett@wdtv.com> - 2014-01-10 21:53 -0500
                              Re: Time zones and why they change so damned often (was: the Gravity of Python 2) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-01-10 19:43 -0500
                              Re: Time zones and why they change so damned often (was: the Gravity of Python 2) Roy Smith <roy@panix.com> - 2014-01-10 19:49 -0500
                          Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 07:10 +0000
                          Re: Time zones and why they change so damned often Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 07:17 +0000
                            Re: Time zones and why they change so damned often Alister <alister.ware@ntlworld.com> - 2014-01-09 12:07 +0000
                              Re: Time zones and why they change so damned often Bob Martin <bob.martin@excite.com> - 2014-01-10 07:31 +0000
                                Re: Time zones and why they change so damned often Alister <alister.ware@ntlworld.com> - 2014-01-10 09:04 +0000
                                  Re: Time zones and why they change so damned often Bob Martin <bob.martin@excite.com> - 2014-01-11 07:52 +0000
                                    Re: Time zones and why they change so damned often Alister <alister.ware@ntlworld.com> - 2014-01-11 11:10 +0000
                                      Re: Time zones and why they change so damned often Alister <alister.ware@ntlworld.com> - 2014-01-11 11:14 +0000
                                      Re: Time zones and why they change so damned often Alister <alister.ware@ntlworld.com> - 2014-01-11 11:14 +0000
                          Re: Time zones and why they change so damned often (was: the Gravity
 of Python 2) Dave Angel <davea@davea.name> - 2014-01-09 10:34 -0500
                      Re: the Gravity of Python 2 Ethan Furman <ethan@stoneleaf.us> - 2014-01-08 17:52 -0800
                      Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 13:09 +1100
                      Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 08:42 +0000
                      Re: the Gravity of Python 2 Ethan Furman <ethan@stoneleaf.us> - 2014-01-09 08:01 -0800
                      Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 18:18 +0000
                      Re: the Gravity of Python 2 Ethan Furman <ethan@stoneleaf.us> - 2014-01-09 10:33 -0800
                Re: the Gravity of Python 2 Pedro Larroy <pedro.larroy.lists@gmail.com> - 2014-01-08 15:45 +0100
                Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 01:50 +1100
                  Re: the Gravity of Python 2 Grant Edwards <invalid@invalid.invalid> - 2014-01-08 15:06 +0000
                    Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 02:31 +1100
                Re: the Gravity of Python 2 Terry Reedy <tjreedy@udel.edu> - 2014-01-08 15:45 -0500
              Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-08 14:15 +0000

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#63556

In article <mailman.5222.1389232077.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> Why not simply use a UTC datetime instead of a naive one?

[Pet peeve of mine: uses of "simple" or "just" to imply that something 
is easy, when it's not.  "Why not just get the Arabs and the Jews to be 
friends?"  "Why not simply find a safe way to store nuclear waste?"]

Because it's easy to get a naive one.  You call datetime.utcnow().  If 
utcnow() returned an aware datetime, that's probably what we would be 
using.  Why didn't utcnow() just return an aware datetime to begin with?

Conversely, it's a pain in the butt to get an aware one.  As far as I 
can tell, you have to do something like:

utcnow().replace(tzinfo=pytz.utc)

which is not only ugly, but requires installing a third-party module 
(pytz) to get the UTC timezone definition.

Not to mention, our database (mongodb), doesn't support storing aware 
datetimes.  I can insert a document with an aware datetime, but when I 
retrieve that document, I get back a naive one.  I don't know what other 
databases do.

[toc] | [prev] | [next] | [standalone]

#63557

On Thu, Jan 9, 2014 at 1:25 PM, Roy Smith <roy@panix.com> wrote:
> Because it's easy to get a naive one.  You call datetime.utcnow().  If
> utcnow() returned an aware datetime, that's probably what we would be
> using.  Why didn't utcnow() just return an aware datetime to begin with?
>
> Conversely, it's a pain in the butt to get an aware one.  As far as I
> can tell, you have to do something like:
>
> utcnow().replace(tzinfo=pytz.utc)
>
> which is not only ugly, but requires installing a third-party module
> (pytz) to get the UTC timezone definition.

What's datetime.today() give you? I'm not experienced with the module,
but a glance at the docs and then a quick try interactively suggests
that this might be what you need.

But even so, the problem is not "why can't naive timestamps do
everything I want". The problem is "why is it so hard to get an aware
timestamp for the current instant". And if you ask *that* question,
then there's likely to be an answer. I might be wrong with my
suggestion above, and maybe there isn't even any answer right now, but
there certainly could be.

Yes, it *is* simple. It *is* easy. I've been working with pure-UTC
times (either called time_t, or TIMESTAMP WITH TIME ZONE, or even just
float) for decades. Like with so many other things, the easiest
solution is also the best, because you can just work with one stable
representation and abstraction on the inside, with conversions to/from
it at the boundaries. It IS that easy.

ChrisA

[toc] | [prev] | [next] | [standalone]

#63559

In article <mailman.5226.1389237436.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Thu, Jan 9, 2014 at 1:25 PM, Roy Smith <roy@panix.com> wrote:
> > Because it's easy to get a naive one.  You call datetime.utcnow().  If
> > utcnow() returned an aware datetime, that's probably what we would be
> > using.  Why didn't utcnow() just return an aware datetime to begin with?
> >
> > Conversely, it's a pain in the butt to get an aware one.  As far as I
> > can tell, you have to do something like:
> >
> > utcnow().replace(tzinfo=pytz.utc)
> >
> > which is not only ugly, but requires installing a third-party module
> > (pytz) to get the UTC timezone definition.
> 
> What's datetime.today() give you?

It almost gives you an aware UTC datetime.  Other than it being naive, 
and being in local time, that is :-)

> But even so, the problem is not "why can't naive timestamps do
> everything I want". The problem is "why is it so hard to get an aware
> timestamp for the current instant". And if you ask *that* question,
> then there's likely to be an answer.

You asked,  Why not simply use a UTC datetime instead
of a naive one?"  My answer is that it's not simple at all.

> Yes, it *is* simple. It *is* easy. I've been working with pure-UTC
> times (either called time_t, or TIMESTAMP WITH TIME ZONE, or even just
> float) for decades. Like with so many other things, the easiest
> solution is also the best, because you can just work with one stable
> representation and abstraction on the inside, with conversions to/from
> it at the boundaries. It IS that easy.

Please show me the simple code to obtain an aware UTC datetime 
representing the current time.

[toc] | [prev] | [next] | [standalone]

#63564

On Thu, Jan 9, 2014 at 2:35 PM, Roy Smith <roy@panix.com> wrote:
>> Yes, it *is* simple. It *is* easy. I've been working with pure-UTC
>> times (either called time_t, or TIMESTAMP WITH TIME ZONE, or even just
>> float) for decades. Like with so many other things, the easiest
>> solution is also the best, because you can just work with one stable
>> representation and abstraction on the inside, with conversions to/from
>> it at the boundaries. It IS that easy.
>
> Please show me the simple code to obtain an aware UTC datetime
> representing the current time.

In Pike:
time();

In PostgreSQL:
SELECT now();

In C:
time(0);

All of these give a value in UTC. The PostgreSQL one gives it to you
as a TIMESTAMP WITH TIME ZONE, the others just as a simple value. I
don't know how they go about figuring out what UTC is, on systems
where the computer clock is in local time (eg Windows), but figure out
they do. It might be expensive but it's done somehow. (Easiest way to
check timezone in C is to look at what time(0)%86400/3600 is - that
should be the hour-of-day in UTC, which as I type is 3. And it is.)

I don't know how to do it in Python because I'm not familiar with the
datetime module. But time.time() returns a value in UTC, which is
verifiable by the above method:

>>> int(time.time())%86400//3600
3

So maybe the key is to use utcfromtimestamp()? I don't know. My
personal preference would be to simply use either int or float
everywhere (float if you need subsecond resolution, int if you're
concerned about massively past or future timestamps), and then
translate to something else for display. Effectively, instead of
working with a datetime object, I would just work with an alternative
representation of instant-in-time which is simply seconds since 1970
(dealing with leap seconds whichever way you like). If the datetime
module causes you pain, don't use it.

Ben, if it's that expensive to get an aware timestamp, why does
time.time() effectively do that? Is it a much more expensive call?

ChrisA

[toc] | [prev] | [next] | [standalone]

#63567

In article <mailman.5231.1389240235.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Thu, Jan 9, 2014 at 2:35 PM, Roy Smith <roy@panix.com> wrote:
> >> Yes, it *is* simple. It *is* easy. I've been working with pure-UTC
> >> times (either called time_t, or TIMESTAMP WITH TIME ZONE, or even just
> >> float) for decades. Like with so many other things, the easiest
> >> solution is also the best, because you can just work with one stable
> >> representation and abstraction on the inside, with conversions to/from
> >> it at the boundaries. It IS that easy.
> >
> > Please show me the simple code to obtain an aware UTC datetime
> > representing the current time.
> 
> In Pike:
> time();
> 
> In PostgreSQL:
> SELECT now();
> 
> In C:
> time(0);
> 
> All of these give a value in UTC.

None of which answer my question.  How, in Python, do you get an aware 
UTC datetime object?  I know how to get a numeric representation of the 
time as the number of seconds since the Unix epoch.  That's not what I 
asked.

> So maybe the key is to use utcfromtimestamp()? I don't know.

So, I'm really confused what point you're trying to make.  You started 
out arguing that I should be using aware datetimes instead of naive 
datetimes.  I said that the reason I don't use aware datetimes is 
because they're so much more difficult to generate.  You said they were 
simple to generate.

So, I'd like to see your code which generates an aware UTC datetime 
object in Python.  And then we can argue about whether it's simple or 
not :-)

[toc] | [prev] | [next] | [standalone]

#63568

On Thu, Jan 9, 2014 at 3:29 PM, Roy Smith <roy@panix.com> wrote:
> So, I'd like to see your code which generates an aware UTC datetime
> object in Python.  And then we can argue about whether it's simple or
> not :-)

Like I said, I don't use the datetime module. But fundamentally, an
aware datetime represents an instant in time - which is exactly what a
POSIX timestamp ("time_t") represents. So I can't offer exact code for
working with them, other than to say that time.time() is precisely
accomplishing the same job. Maybe there needs to be a recipe posted
somewhere saying "To create a datetime from a POSIX time, do this".

This is simple:

>>> time.time()
1389242048.669482

ChrisA

[toc] | [prev] | [next] | [standalone]

#63569

On Thu, Jan 9, 2014 at 3:29 PM, Roy Smith <roy@panix.com> wrote:
> So, I'd like to see your code which generates an aware UTC datetime
> object in Python.  And then we can argue about whether it's simple or
> not :-)

In fact, I'll go further. Why do you need a datetime object at all?
What is it that you need? Arithmetic can be done with int and/or
float, parsing and formatting can be done with time.str[pf]time, etc,
etc. It's like if someone asks "How can I build a regular expression
that will tell me if a string is valid JSON?". The question poses a
restriction that may be unnecessary, and may eliminate all possible
answers.

ChrisA

[toc] | [prev] | [next] | [standalone]

#63570

On 01/08/2014 08:34 PM, Chris Angelico wrote:
> On Thu, Jan 9, 2014 at 3:29 PM, Roy Smith <roy@panix.com> wrote:
>> So, I'd like to see your code which generates an aware UTC datetime
>> object in Python.  And then we can argue about whether it's simple or
>> not :-)
>
> Like I said, I don't use the datetime module. But fundamentally, an
> aware datetime represents an instant in time - which is exactly what a
> POSIX timestamp ("time_t") represents. So I can't offer exact code for
> working with them, other than to say that time.time() is precisely
> accomplishing the same job. Maybe there needs to be a recipe posted
> somewhere saying "To create a datetime from a POSIX time, do this".
>
> This is simple:
>
>>>> time.time()
> 1389242048.669482

I agree, and I'm sure Roy also agrees, that that is simple.  However, that is *not* a timezone-aware datetime.  The 
point of having the datetime module is so we all don't have to reroll our own from scratch, and yet this particular (and 
increasingly important) operation wasn't intuitive nor easy.


http://docs.python.org/dev/library/datetime.html?highlight=datetime#datetime.tzinfo
===================================================================================

class datetime.tzinfo

     An abstract base class for time zone information objects. These are used by the datetime and time classes to 
provide a customizable notion of time adjustment (for example, to account for time zone and/or daylight saving time).

class datetime.timezone

     A class that implements the tzinfo abstract base class as a fixed offset from the UTC.

     New in version 3.2.

Objects of these types are immutable.

Objects of the date type are always naive.

An object of type time or datetime may be naive or aware. A datetime object d is aware if d.tzinfo is not None and 
d.tzinfo.utcoffset(d) does not return None. If d.tzinfo is None, or if d.tzinfo is not None but d.tzinfo.utcoffset(d) 
returns None, d is naive. A time object t is aware if t.tzinfo is not None and t.tzinfo.utcoffset(None) does not return 
None. Otherwise, t is naive.
===================================================================================

That is not simple.

This however, may qualify (emphasis added):
===================================================================================
classmethod datetime.utcnow()

     Return the current UTC date and time, with tzinfo None. This is like now(), but returns the current UTC date and 
time, as a naive datetime object. An aware current UTC datetime can be obtained by calling *datetime.now(timezone.utc)*. 
See also now().
===================================================================================

It looks like the .fromtimestamp also accepts tz=timezone.utc, so perhaps that is the simple way to get the timezone 
aware datetime.  I haven't tested, I'm going to bed.  :/

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#63575

On Thu, Jan 9, 2014 at 4:31 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
> On 01/08/2014 08:34 PM, Chris Angelico wrote:
>>
>> This is simple:
>>
>>>>> time.time()
>>
>> 1389242048.669482
>
>
> I agree, and I'm sure Roy also agrees, that that is simple.  However, that
> is *not* a timezone-aware datetime.  The point of having the datetime module
> is so we all don't have to reroll our own from scratch, and yet this
> particular (and increasingly important) operation wasn't intuitive nor easy.

What exactly does datetime offer you that a timestamp doesn't? Can we
get a quick run-down, please?

ChrisA

[toc] | [prev] | [next] | [standalone]

#63576

Chris Angelico <rosuav@gmail.com> writes:

> What exactly does datetime offer you that a timestamp doesn't? Can we
> get a quick run-down, please?

Isn't this answered by you reading the standard library documentation
for the ‘datetime’ and ‘time’ modules? Are you asking for someone to
read those for you? If not, can you explain more precisely what you're
asking?

-- 
 \         “A child of five could understand this. Fetch me a child of |
  `\                                              five.” —Groucho Marx |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#63581

On Thu, Jan 9, 2014 at 5:57 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> What exactly does datetime offer you that a timestamp doesn't? Can we
>> get a quick run-down, please?
>
> Isn't this answered by you reading the standard library documentation
> for the ‘datetime’ and ‘time’ modules? Are you asking for someone to
> read those for you? If not, can you explain more precisely what you're
> asking?

Sorry. I'm more specifically asking what Roy's using, here. I can see
what functions it offers, so my language was a bit sloppy. What I
meant is: What can you (Roy), with your use-case, achieve with
datetime that you can't achieve (at least reasonably easily) with a
timestamp? Nobody ever uses every feature of a module, and I often see
people using some library/module/function when they could be using a
simpler and easier base function (like using JQuery for basic web page
scripting).

ChrisA

[toc] | [prev] | [next] | [standalone]

#63598

In article <mailman.5244.1389254198.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> What can you (Roy), with your use-case, achieve with datetime that 
> you can't achieve (at least reasonably easily) with a timestamp?

As I'm mentioned several times, when you print a datetime, you get 
something that's human friendly.  When you print a timestamp (i.e. a 
float), you get a lot of digits.  I don't know about you, but I can't 
look at 1389274842 and get any feel for whether that was in the middle 
of the night or at 5 in the afternoon, near our peak traffic time.  Nor 
can I tell if it was today, yesterday, last month, or a week from next 
Tuesday.

Datetimes make it easy to do things like, "find the time of the 
preceding (or following) midnight".  Or, "what month is this timestamp 
part of?"  These are operations we need to do a lot, to answer questions 
like, "How many unique users did we have on a given day?", or "Which 
monthly database archive file do I need to grab to get information about 
this historical event?"

Datetimes are self-documenting.  If I'm in the python shell and have 
something called t, I can do help(t) or dir(t) to find out what 
operations it has.

Datetimes are self-describing.  If I have a datetime or a timedelta, I 
know what I've got.  I've written more than one bug where I assumed a 
number somebody handed me was in seconds but it turned out to be in ms.  
That can never happen with a timedelta.  We do a lot of stuff in 
javascript, where times are ms, so this is a common problem for us.

Oh, and another thing I can do with a datetime that I can't do with a 
unix timestamp.  I can represent the day I was born.

[toc] | [prev] | [next] | [standalone]

#63602

On Fri, Jan 10, 2014 at 1:14 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.5244.1389254198.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
>
>> What can you (Roy), with your use-case, achieve with datetime that
>> you can't achieve (at least reasonably easily) with a timestamp?

Thanks for this collection! Now we can discuss.

> As I'm mentioned several times, when you print a datetime, you get
> something that's human friendly.  When you print a timestamp (i.e. a
> float), you get a lot of digits.  I don't know about you, but I can't
> look at 1389274842 and get any feel for whether that was in the middle
> of the night or at 5 in the afternoon, near our peak traffic time.  Nor
> can I tell if it was today, yesterday, last month, or a week from next
> Tuesday.

Sure. There is a lot of value in having a class that knows how it
should be displayed. I'm not sure the current datetime repr is good
for anything more than debugging, but I agree that
"datetime.datetime(2014, 1, 9, 5, 57, 59, 929176)" is more likely to
be useful than a raw number.

> Datetimes make it easy to do things like, "find the time of the
> preceding (or following) midnight".  Or, "what month is this timestamp
> part of?"  These are operations we need to do a lot, to answer questions
> like, "How many unique users did we have on a given day?", or "Which
> monthly database archive file do I need to grab to get information about
> this historical event?"

That's true; the same operations done with timestamps look like this:

>>> ts = time.time()
>>> ts_at_midnight_utc = ts - ts%86400
>>> ts_at_midnight_utc
1389225600.0

Not nearly as obvious what's happening. And months are more
complicated still, so it's probably easiest to use strftime:

>>> time.strftime("%Y%m",time.gmtime(ts))
'201401'

which could then be used as a lookup key for a counter or whatever.
Yep, that's not as clean as simply calling a method.

> Datetimes are self-documenting.  If I'm in the python shell and have
> something called t, I can do help(t) or dir(t) to find out what
> operations it has.

Partly true, but not everything's there. For instance, if you have a
list of strings, you won't find a way to join them together in its
help() or dir(), and yet it's a fundamental and very important
operation.

> Datetimes are self-describing.  If I have a datetime or a timedelta, I
> know what I've got.  I've written more than one bug where I assumed a
> number somebody handed me was in seconds but it turned out to be in ms.
> That can never happen with a timedelta.  We do a lot of stuff in
> javascript, where times are ms, so this is a common problem for us.

Sure. Though that's no different from other cases where you need
out-of-band information to understand something, as we've just been
discussing in the threads about text handling - if you have a puddle
of bytes, you can't decode them to text without knowing what the
encoding is. [1] If your data's coming from JS, it won't be a
timedelta, it'll be a number; at some point you have to turn that into
a timedelta object, so you still have the same problem.

> Oh, and another thing I can do with a datetime that I can't do with a
> unix timestamp.  I can represent the day I was born.

Maybe you can't with the original C definition of time_t as an
unsigned integer, but the notion of a Unix timestamp can plausibly be
extended (a) to negative numbers, and (b) to non-integers. Python
definitely does the latter; its ability to do the former depends
somewhat on the underlying C library's support:

Windows:
>>> time.strftime("%Y%m",time.gmtime(-100000))
Traceback (most recent call last):
  File "<pyshell#163>", line 1, in <module>
    time.strftime("%Y%m",time.gmtime(-100000))
OSError: [Errno 22] Invalid argument

Linux:
>>> time.strftime("%Y%m",time.gmtime(-100000))
'196912'
>>> time.strftime("%Y%m",time.gmtime(-2**31))
'190112'
>>> time.strftime("%Y%m",time.gmtime(-2**31-1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: timestamp out of range for platform time_t

So what I'm seeing here is that the direct use of a time_t will cover
everything in an ugly way, but that a class wrapping it up could fix
that. And fundamentally, the only problem with datetime (which, for
the most part, is exactly that wrapper) is that it's unobvious how to
get a simple UTC timestamp.

Has the unobviousness been solved by a simple recipe? And if so,
should that tip be added to the datetime module docs somewhere?

ChrisA

[1] Yes, I said "puddle of bytes". What would you call it? Am
interested to hear!

[toc] | [prev] | [next] | [standalone]

#63611

On Thursday, January 9, 2014 9:57:57 AM UTC-5, Chris Angelico wrote:


> And months are more
> complicated still, so it's probably easiest to use strftime:
> 
> >>> time.strftime("%Y%m",time.gmtime(ts))
> 
> '201401'

strftime is a non-starter at far as "easy" goes.  I don't know about you, but I certainly haven't memorized the table of all the format specifiers.  Is month "m" or "M"?  What's "%U" or "%B".  Every time I use strftime, I have to go pull up the docs and read the table.  Not to mention that "%z" is not available on all platforms, and "%s" (which is incredibly useful) is not even documented (I suspect it's also not available on all platforms).

> So what I'm seeing here is that the direct use of a time_t will cover
> everything in an ugly way, but that a class wrapping it up could fix
> that. And fundamentally, the only problem with datetime (which, for
> the most part, is exactly that wrapper) is that it's unobvious how to
> get a simple UTC timestamp.
> 
> Has the unobviousness been solved by a simple recipe? And if so,
> should that tip be added to the datetime module docs somewhere?

No, it would be solved by a built-in method.  Recipes are a cop-out.  If something is complicated enough to require a recipe, and used frequently enough to be worth writing that recipe up and documenting it, you might as well have gone the one additional step and made it a method.

[toc] | [prev] | [next] | [standalone]

#63612

On 09/01/2014 16:21, Roy Smith wrote:
>
> No, it would be solved by a built-in method.  Recipes are a cop-out.  If something is complicated enough to require a recipe, and used frequently enough to be worth writing that recipe up and documenting it, you might as well have gone the one additional step and made it a method.
>

So all of the itertools recipes should be part of the Python module and 
not in more-itertools on pypi?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#63620

I wrote:
> Recipes are a cop-out

On Thursday, January 9, 2014 11:30:31 AM UTC-5, Mark Lawrence wrote:
> So all of the itertools recipes should be part of the Python module and 
> not in more-itertools on pypi?

Certainly, the recipes that are documented on the official itertools page, yes.

[toc] | [prev] | [next] | [standalone]

#63623

On 09/01/2014 17:07, Roy Smith wrote:
> I wrote:
>> Recipes are a cop-out
>
> On Thursday, January 9, 2014 11:30:31 AM UTC-5, Mark Lawrence wrote:
>> So all of the itertools recipes should be part of the Python module and
>> not in more-itertools on pypi?
>
> Certainly, the recipes that are documented on the official itertools page, yes.
>

No thank you, I don't want the Python docs getting anywhere near the 
size of their Java equivalents.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#63625

On 01/09/2014 10:20 AM, Mark Lawrence wrote:
>> On Thursday, January 9, 2014 11:30:31 AM UTC-5, Mark Lawrence wrote:
>>> So all of the itertools recipes should be part of the Python module and
>>> not in more-itertools on pypi?
>>
>> Certainly, the recipes that are documented on the official itertools page, yes.
>
> No thank you, I don't want the Python docs getting anywhere near the size of their Java equivalents.

To be fair, the recipes on the itertools page are there so that minor changes can be made (flavor to taste, so to speak) 
to get exactly the semantics needed by the individual programmer.

With the timezone stuff we're looking for The One Obvious Way, which should be a method, not a recipe.

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#63613

On 09/01/2014 16:30, Mark Lawrence wrote:
> On 09/01/2014 16:21, Roy Smith wrote:
>>
>> No, it would be solved by a built-in method.  Recipes are a cop-out. 
>> If something is complicated enough to require a recipe, and used
>> frequently enough to be worth writing that recipe up and documenting
>> it, you might as well have gone the one additional step and made it a
>> method.
>>
> 
> So all of the itertools recipes should be part of the Python module and
> not in more-itertools on pypi?

To be fair, Mark, it's a matter of taste. Raymond [the author/maintainer
of itertools] prefers not to multiply the API; other developers might
legitimately make other calls. Sometimes the cut-off is more obvious;
say, when the effort to make a recipe general purpose creates an
over-engineered API. Other times it's just preference.

Does that mean that every recipe ever conceived should be stuffed into
the class or module it uses? No; but it doesn't rule out adding things
which are genuinely useful.

I think the new statistics module has hit a nice balance on its initial
release: it's a stripped down aesthetic without precluding later additions.

TJG

[toc] | [prev] | [next] | [standalone]

#63614

> and "%s" (which is incredibly useful) is not even documented (I suspect it's also not available on all platforms).

The format specifiers available to Python are just whatever is available to the underlying c time.h. 
The manpage for strftime indicates that %s isn't part of the C standard, but part of "Olson's timezone package", which means it's not available on Windows. Your suspicion is unfortunately correct.

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web