On Wed, Jun 6, 2012 at 10:18 AM, Barry Warsaw <ba...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
