On 28 Jul 2015, at 03:13, Tres Seaver email@example.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.