[Python-Dev] Status on PEP-431 Timezones

[Ronald Oussoren]

> On 28 Jul 2015, at 03:13, Tres Seaver <tseaver at palladion.com> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07/27/2015 06:11 PM, Ronald Oussoren wrote:
> 
>> Treating time as UTC with conversions at the application edge might
>> be "cleaner" in some sense, but can make code harder to read for 
>> application domain experts.
>> 
>> It might be nice to have time zone aware datetime objects with the 
>> right(TM) semantics, but those can and should not replace the naive 
>> objects we know and love.
> 
> Interesting.  My experience is exactly the opposite:  the datetimes which
> "application domain experts" cared about *always* needed to be non-naive
> (zone captured explicitly or from the user's machine and converted to
> UTC/GMT for storage).  As with encoded bytes, allowing a naive instance
> inside the borders the system was always a time-bomb bug (stuff would
> blow up at a point far removed from which it was introduced).
> 
> The instances which could have safely been naive were all
> logging-related, where the zone was implied by the system's timezone
> (nearly always UTC).  I guess the difference is that I'm usually writing
> apps whose users can't be presumed to be in any one timezone.  Even in
> those cases, having the logged datetimes be incomparable to user-facing
> ones would make them less useful.

I usually write application used by local users where the timezone is completely
irrelevant, including DST.  Stuff needs to be done at (say) 8PM, ands that’s
8PM local time. Switching to and from UTC just adds complications. 

I’m lucky enough that most datetime calculations happen within one work week
and therefore never have to cross DST transitions.  For longer periods I usually
only care about dates, and almost never about the number of seconds between
two datetime instances.   That makes the naive datetime from the stdlib a 
very convenient programming model.

And I’m in a country that’s small enough to have only one timezone.

IMHO Unicode is different in that regard, there the application logic can clearly
be expressed as text and the encoding to/from bytes can safely be hidden in
the I/O layer. Often the users I deal with can follow the application logic w.r.t.
text handling, but have no idea about encodings (but do care about accented
characters). With some luck they can provide a sample file that allows me to 
deduce the encoding that should be used, and most applications are moving 
to UTF-8.

BTW. Note that I’m not saying that a timezone aware datetime is bad, just
that they are not always necessary.

Ronald