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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#63618

On 09/01/2014 16:42, Nick Cash wrote:
>> 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.
>

Methinks http://www.python.org/dev/peps/pep-0431/ Time zone support 
improvements may be of interest here.  Still at draft issue unfortunately.

-- 
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]

#63630

On Fri, Jan 10, 2014 at 3:21 AM, Roy Smith <roy@panix.com> wrote:
> 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).
>

Have you ever used a regular expression? Does it bother you that both
percent-formatting and str.format() have compact/cryptic
mini-languages? Why is it a problem to have a mini-language for
formatting dates? It at least follows a measure of common sense,
unlike the PHP date function. In fact, I've given end users the
ability to enter strftime strings (eg to construct a filename), and
it's worked just fine. *Non-programmers* can figure them out without
much difficulty.

ChrisA

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

#63633

On Thursday, January 9, 2014 3:35:05 PM UTC-5, Chris Angelico wrote:
> In fact, I've given end users the ability to enter strftime strings (eg
> to construct a filename), and it's worked just fine.

I assume you realize that "../../../../../../../../../../../../../../../../etc/passwd" is a valid strftime() format specifier? :-)

But, to answer your question, no, I have nothing against small languages, per-se (and I've done plenty of regex work).  But, if my goal is to print a time in some human-readable form:

>>> print t

is a lot easier than anything involving strftime().

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

#63637

On Fri, Jan 10, 2014 at 7:54 AM, Roy Smith <roy@panix.com> wrote:
> On Thursday, January 9, 2014 3:35:05 PM UTC-5, Chris Angelico wrote:
>> In fact, I've given end users the ability to enter strftime strings (eg
>> to construct a filename), and it's worked just fine.
>
> I assume you realize that "../../../../../../../../../../../../../../../../etc/passwd" is a valid strftime() format specifier? :-)

Yes, and since this was for the creation of a log file by an
unprivileged process, that would simply fail :) Though the specific
case I'm thinking of here was on Windows, so you could probably find
an equivalent filename (it didn't prevent absolute names, so you could
just stuff whatever you want in) and shoot yourself in the foot
big-time. It's the user's own system, let him make a mess of it if he
wants :)

> But, to answer your question, no, I have nothing against small languages, per-se (and I've done plenty of regex work).  But, if my goal is to print a time in some human-readable form:
>
>>>> print t
>
> is a lot easier than anything involving strftime().

Sure, it's easier. But there are plenty of types that don't provide a
particularly useful repr - regexes being one that only recently
changed:

2.7 and 3.3:
>>> re.compile(r"(.)\1\1\1")
<_sre.SRE_Pattern object at 0x012464F0>
>>> _.search("This is a test string with a quadrrrruple letter in it!")
<_sre.SRE_Match object at 0x012C3EE0>

3.4:
>>> re.compile(r"(.)\1\1\1")
re.compile('(.)\\1\\1\\1')
>>> _.search("This is a test string with a quadrrrruple letter in it!")
<_sre.SRE_Match object; span=(33, 37), match='rrrr'>

Would you avoid using regexes in anything less than 3.4 simply because
of this lack of repr? It's a convenience, not a deal-breaker. (Or if
you disagree with me on that point, you're cutting out a lot of very
useful types.) It's not hard to call time.ctime(ts) or strftime(...)
for display; the big loser is the interactive interpreter, where a
good repr is everything.

ChrisA

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

#63603

On Thu, 09 Jan 2014 09:14:22 -0500, Roy Smith wrote:

> 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.

At the risk of dating myself, the day I was born is -231094800.

Dan

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

#63605

On Fri, Jan 10, 2014 at 2:01 AM, Dan Sommers <dan@tombstonezero.net> wrote:
> On Thu, 09 Jan 2014 09:14:22 -0500, Roy Smith wrote:
>
>> 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.
>
> At the risk of dating myself, the day I was born is -231094800.

Which, according to a Unix build of Python, is quite representable:

>>> time.strftime("%Y-%m-%d",time.gmtime(-231094800))
'1962-09-05'

This isn't a problem. Now, if you were considering yourself for a
romantic candle-lit dinner and a movie afterward, then maybe there's
some risk in dating yourself :)

ChrisA

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

#63615

On 01/09/2014 06:57 AM, Chris Angelico wrote:
> On Fri, Jan 10, 2014 at 1:14 AM, Roy Smith <roy@panix.com> wrote:
>>
>
> Thanks for this collection! Now we can discuss.

[snip]

>> 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.

Yup, and you do at the boundary instead of having a float wandering through your code with an easily forgotten meta-data 
type.


> 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.

It has at least one other problem:  bool(midnight) == False.

--
~Ethan~


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

I think that's a perfect name!  :)

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

#63583

[Multipart message — attachments visible in raw view] — view raw

Roy Smith <roy@panix.com> writes:

> 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.
>

My local copy of the python 3.2.3 docs says:

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().

Hope this helps.

>> 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 :-)

-- 
regards,
kushal

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

#63585

On 09/01/2014 06:06, Kushal Kumaran wrote:
>
> My local copy of the python 3.2.3 docs says:
>
> 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().
>
> Hope this helps.
>

Blimey, you learn something new everyday, thanks.  And it works :)

In [7]: datetime.datetime.now(datetime.timezone.utc)
Out[7]: datetime.datetime(2014, 1, 9, 8, 51, 13, 945312, 
tzinfo=datetime.timezone.utc)

-- 
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]

#63586

Kushal Kumaran <kushal.kumaran@gmail.com> writes:

> Roy Smith <roy@panix.com> writes:
> > How, in Python, do you get an aware UTC datetime object?
>
> My local copy of the python 3.2.3 docs says:
>
> 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().
>
> Hope this helps.

No, that won't do what was asked. The ‘datetime.datetime.utcnow’
function explicitly returns a naive datetime object, not an aware
datetime object.

-- 
 \       “We must respect the other fellow's religion, but only in the |
  `\       sense and to the extent that we respect his theory that his |
_o__)     wife is beautiful and his children smart.” —Henry L. Mencken |
Ben Finney

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

#63587

[Multipart message — attachments visible in raw view] — view raw

Ben Finney <ben+python@benfinney.id.au> writes:

> Kushal Kumaran <kushal.kumaran@gmail.com> writes:
>
>> Roy Smith <roy@panix.com> writes:
>> > How, in Python, do you get an aware UTC datetime object?
>>
>> My local copy of the python 3.2.3 docs says:
>>
>> 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().
>>
>> Hope this helps.
>
> No, that won't do what was asked. The ‘datetime.datetime.utcnow’
> function explicitly returns a naive datetime object, not an aware
> datetime object.
>

Yes, but the documentation for utcnow explicitly tells you how to get
an aware object.

  "An aware current UTC datetime can be obtained by calling
   datetime.now(timezone.utc)."

-- 
regards,
kushal

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

#63592

Kushal Kumaran <kushal.kumaran@gmail.com> writes:

> Yes, but the documentation for utcnow explicitly tells you how to get
> an aware object.
>
>   "An aware current UTC datetime can be obtained by calling
>    datetime.now(timezone.utc)."

And in Python 2.7 you can just copy the definition of utc from the doc and use that:

from datetime import tzinfo, timedelta, datetime

ZERO = timedelta(0)

class UTC(tzinfo):
    """UTC"""

    def utcoffset(self, dt):
        return ZERO

    def tzname(self, dt):
        return "UTC"

    def dst(self, dt):
        return ZERO

utc = UTC()
-- 
Piet van Oostrum <piet@vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]

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

#63588

On 09/01/2014 09:03, Ben Finney wrote:
> Kushal Kumaran <kushal.kumaran@gmail.com> writes:
>
>> Roy Smith <roy@panix.com> writes:
>>> How, in Python, do you get an aware UTC datetime object?
>>
>> My local copy of the python 3.2.3 docs says:
>>
>> 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().
>>
>> Hope this helps.
>
> No, that won't do what was asked. The ‘datetime.datetime.utcnow’
> function explicitly returns a naive datetime object, not an aware
> datetime object.
>

How closely do you bother to read posts that people like Kushal Kumaran 
have taken the trouble to post?  Eleven lines above this one it says (my 
emphasis) "An *AWARE* current UTC datetime can be obtained by
calling datetime.now(timezone.utc)".

-- 
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]

#63596

Kushal Kumaran <kushal.kumaran@gmail.com> writes:

> Ben Finney <ben+python@benfinney.id.au> writes:
>
> > Kushal Kumaran <kushal.kumaran@gmail.com> writes:
> >
> >> Roy Smith <roy@panix.com> writes:
> >> > How, in Python, do you get an aware UTC datetime object?
> >>
> >> classmethod datetime.utcnow()
> >>
> >>     Return the current UTC date and time, with tzinfo None. […]
> >
> > No, that won't do what was asked. The ‘datetime.datetime.utcnow’
> > function explicitly returns a naive datetime object, not an aware
> > datetime object.
>
> Yes, but the documentation for utcnow explicitly tells you how to get
> an aware object.
>
>   "An aware current UTC datetime can be obtained by calling
>    datetime.now(timezone.utc)."

And we come full circle: This is exactly what Roy's original question
was (IIUC) trying to address. That process is not obvious, and it's not
simple: it's a series of difficult-to-discover function calls instead of
just one obvious one.

-- 
 \       “If you don't know what your program is supposed to do, you'd |
  `\                 better not start writing it.” —Edsger W. Dijkstra |
_o__)                                                                  |
Ben Finney

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

#63599

In article <mailman.5257.1389274514.18130.python-list@python.org>,
 Ben Finney <ben+python@benfinney.id.au> wrote:

> Kushal Kumaran <kushal.kumaran@gmail.com> writes:
> 
> > Ben Finney <ben+python@benfinney.id.au> writes:
> >
> > > Kushal Kumaran <kushal.kumaran@gmail.com> writes:
> > >
> > >> Roy Smith <roy@panix.com> writes:
> > >> > How, in Python, do you get an aware UTC datetime object?
> > >>
> > >> classmethod datetime.utcnow()
> > >>
> > >>     Return the current UTC date and time, with tzinfo None. […]
> > >
> > > No, that won't do what was asked. The ‘datetime.datetime.utcnow’
> > > function explicitly returns a naive datetime object, not an aware
> > > datetime object.
> >
> > Yes, but the documentation for utcnow explicitly tells you how to get
> > an aware object.
> >
> >   "An aware current UTC datetime can be obtained by calling
> >    datetime.now(timezone.utc)."
> 
> And we come full circle: This is exactly what Roy's original question
> was (IIUC) trying to address. That process is not obvious, and it's not
> simple: it's a series of difficult-to-discover function calls instead of
> just one obvious one.

Yes, exactly.  Thank you.

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

#63558

Chris Angelico <rosuav@gmail.com> writes:

> 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?
[…]

> 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 think Roy's question hits close to a related problem: that the
standard library makes it easy to do a sub-optimal thing, and the
behaviour we all agree is best is not the default.

So, two questions are raised. One is what you've correctly identified:
“Why is it so hard to get an aware timestamp for the current instant?”
The short answer is: because doing that requires a lookup into a
frequently-updated database, which (because it's so frequently updated)
isn't installed along with Python.

The other is: “Why is the default behaviour from the standard library
doing something which I later discover is the wrong thing to do?” The
answer to that is, of course, related to the first one: the right thing
to do isn't currently feasible by default. Not a very satisfactory
answer, but nevertheless a situation we need to deal with today.

> 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.

The difficulty isn't in doing the right thing; the difficulty is in
doscovering that the default behaviour is sub-optimal and then learning
what, exactly *is* the right thing to do.

The right behaviour is easy, but it's not default, and it's not obvious,
and it's a difficult learning process to differentiate the right thing
to do from the several competing easier-to-understand but wrong things.

So, I think you're both correct. The messiness of getting to the right
behaviour is highly obnoxious and technically unnecessary, if only the
bureaucrats and politicians would give up trying to make their mark on
time zones <URL:https://www.youtube.com/watch?v=-5wpm-gesOY>.

With time zones, as with text encodings, there is a single technically
elegant solution (for text: Unicode; for time zones: twelve simple,
static zones that never change) that would work for the whole world if
we could just be free to sweep away all the messy legacy crap and expect
people to stop complicating the matter further.

Until that day comes, though, we as programmers need to learn this messy
arbitrary crap, at least to the point of knowing unambiguously what we
ask the computer to do when it interacts with the messy real world.

-- 
 \           “I prayed for twenty years but received no answer until I |
  `\          prayed with my legs.” —Frederick Douglass, escaped slave |
_o__)                                                                  |
Ben Finney

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

#63561

In article <mailman.5227.1389238511.18130.python-list@python.org>,
 Ben Finney <ben+python@benfinney.id.au> wrote:

> Chris Angelico <rosuav@gmail.com> writes:
> 
> > 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?
> […]
> 
> > 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 think Roy's question hits close to a related problem: that the
> standard library makes it easy to do a sub-optimal thing, and the
> behaviour we all agree is best is not the default.
> 
> So, two questions are raised. One is what you've correctly identified:
> “Why is it so hard to get an aware timestamp for the current instant?”
> The short answer is: because doing that requires a lookup into a
> frequently-updated database, which (because it's so frequently updated)
> isn't installed along with Python.

We have a call in the standard library named utcnow().  That shouldn't 
require a lookup in a database.  "I'm sorry, which value of zero did you 
want?"

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

#63560

On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> [ a bunch of stuff that I totally agree with ]

No response needed here :)

So I was wrong on the specific example of .today(), but asking the
question the other way is at least helpful. Maybe the best solution is
exactly what Roy already posted, or maybe there's some other way to
achieve that. In any case, there is a solution, albeit not as clean as
I would have liked.

> With time zones, as with text encodings, there is a single technically
> elegant solution (for text: Unicode; for time zones: twelve simple,
> static zones that never change)

Twelve or twenty-four? Or are you thinking we should all be an even
number of hours away from UTC, which would also work?

ChrisA

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

#63597

Chris Angelico <rosuav@gmail.com> writes:

> On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
>> [ a bunch of stuff that I totally agree with ]
>
> No response needed here :)
>
> So I was wrong on the specific example of .today(), but asking the
> question the other way is at least helpful. Maybe the best solution is
> exactly what Roy already posted, or maybe there's some other way to
> achieve that. In any case, there is a solution, albeit not as clean as
> I would have liked.
>
>> With time zones, as with text encodings, there is a single technically
>> elegant solution (for text: Unicode; for time zones: twelve simple,
>> static zones that never change)
>
> Twelve or twenty-four? Or are you thinking we should all be an even
> number of hours away from UTC, which would also work?

Even 24 doesn't take into account DST.
-- 
Piet van Oostrum <piet@vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]

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

#63600

On Fri, Jan 10, 2014 at 1:06 AM, Piet van Oostrum <piet@vanoostrum.org> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
>>> With time zones, as with text encodings, there is a single technically
>>> elegant solution (for text: Unicode; for time zones: twelve simple,
>>> static zones that never change)
>>
>> Twelve or twenty-four? Or are you thinking we should all be an even
>> number of hours away from UTC, which would also work?
>
> Even 24 doesn't take into account DST.

That was the point. We can abolish codepages by using Unicode, which
covers everything. We could abolish time messes by having every
locality settle permanently on one timezone; Ben's theory demands that
all timezones be some integer number of hours +/- UTC, which IMO is
optional, but mainly it should be easy to figure out any two
locations' difference: just subtract one's UTC offset from the
other's. Similarly, you can calculate the difference between two times
at the same location by simple subtraction; currently, you also have
to consider the possibility of a DST switch (from noon to noon across
a switch is either 23 or 25 hours).

Actually, the nearest parallel to Unicode is probably "use UTC
everywhere", which makes for a superb internal representation and
transmission format, but bugs most human beings :)

ChrisA

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

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

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

csiph-web