[Python-Dev] TZ-aware local time

[Nick Coghlan]

On Wed, Jun 6, 2012 at 10:18 AM, Barry Warsaw <barry at python.org> wrote:
> On Jun 05, 2012, at 07:41 PM, Alexander Belopolsky wrote:
>
>>The second feature has its uses.  If I want wake up at 7 AM every
>>weekday, I don't want my alarm clock ask me whether I mean standard or
>>daylight saving time, but if I attempt to set it to 1:30 AM on the day
>>when 1:30 AM happens twice, I don't want it to go off twice or divine
>>which 1:30 AM I had in mind.  I think stdlib should allow me to write
>>a robust application that knows that some naive datetime objects
>>correspond to two points in time and some correspond to none.
>
> Really?  Why would naive datetimes know that?  I would expect that an aware
> datetime would have that information but not naive ones.

Indeed. As I mentioned in my earlier email, we need to remember that
there's a *system* level solution to many of these problems Alexander
raises: configure machines to use UTC and completely ignore local time
definitions.

Many military systems do this. They schedule everything in Zulu time
anyway, and have the kind of control over their mission critical
systems that means they can enforce the rule of configuring absolutely
everything to run as UTC. Such systems often span multiple time zones,
and sharing a consistent time base with other system components is
considered far more important than the vagaries of local time
definitions (coping with DST is the least of your worries in that
context, since you would also need to consider situations like entire
countries deciding to change time zones:
http://www.bbc.co.uk/news/world-13334229).

You *cannot* do robust date processing with local times, because the
meaning of "local time" changes. Clients, servers, peers, will all
have different ideas about the local time, but they will all agree on
UTC. For some platforms (especially supersonic aircraft, satellites
and extraplanetary exploration vehicles) the very notion of "local
time" is completely meaningless (the International Space Station takes
90 minutes to complete an orbit, so it takes less than 4 minutes to
cross any given terrestrial "time zone"). And if everything is known
to be in UTC, then it doesn't matter if you're using "naive" timezone
objects, or "aware" ones that happen to have their timezone
specifically set to UTC. Local time should only be used for displaying
dates and times to humans (since we care about little things like
local sunrise and sunset, local business hours, etc) and for
inter-system coordination where such details are relevant.

It's analagous to the situation with Unicode text and encodings: the
"true" time representation is UTC, just as the "true" text
representation is Unicode. "tzinfo" objects are the date/time
equivalent of Unicode encodings. Passing tzinfo objects around is the
equivalent of using "tagged bytestrings" (i.e. binary data with an
associated encoding) as your internal representation instead of a
Unicode based text object.

You really want to deal with timezone variations solely at your system
boundaries and get rid of them ASAP when it comes to internal
processing.

The datetime module should be designed to make this *as easy as
possible*. Adding a "local time" tzinfo object (with the ambigous hour
favouring the non-DST time, and the missing hour triggering an error
at construction time) would be a good step in the right direction: it
allows local times to be clearly flagged, even though they're
explicitly *not* appropriate for many kinds of processing and need to
be converted to a more suitable format (such as a naive datetime
object, or one with the timezone set to UTC) first. This is directly
analogous to text in a specific encoding: it's useful for some
purposes, but you'll need to decode it to Unicode for many other
manipulations.

Personally, I'd like to see the datetime module make an explicit
assumption that "all naive datetime objects are considered to be UTC",
with the interactions between naive and aware objects updated
accordingly. (The difference between this and the implicit conversion
hell that is the Python 2 Unicode model is that there shouldn't be a
range mismatch between the canonical time representation and the
timezone aware representations the way there is between the range of
the full Unicode representation and what can be represented in an
arbitrary text encoding).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia