On Tue, Jun 5, 2012 at 6:49 PM, Guido van Rossum <gu...@python.org> wrote: >> The problem is again the DST ambiguity. One day a year, datetime(y, >> m, d, 1, 30, tzinfo=Local) represents two different times and another >> day it represents no valid time. Many applications can ignore this >> problem but stdlib should not. > > This seems the blocking issue. We disagree on whether the stdlib > should not offer this functionality because it cannot do so perfectly. >
I would put it differently. There are two features missing from datetime: 1. We cannot create TZ-aware local time datetime objects from a timestamp. In other words, if I want to implement UNIX date utility: $ date Tue Jun 5 18:56:50 EDT 2012 I have to use the lower level time module. 2. We cannot imbue a naive datetime object presumed to represent local time with a tzinfo instance. Note that the first feature does not suffer from the DST ambiguity. Many modern systems extend POSIX struct tm to supply accurate UTC offset and zone name taking into account all historical changes. 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. This does not preclude implementing LocalTimezone, but we have to decide what to do if user specifies ambiguous or invalid naive time. My preference would be to default to standard time for the ambiguous hour and raise a ValueError for the invalid hour. >> The documentation example (fixed in issue 9063) addresses the >> ambiguity by defaulting to standard time, but it does this at a cost >> of having no way to spell "the other hour." > > Again, this is a problem of DST and timezones, and not something you > can ever "fix" ... POSIX has the "fix." It is not perfect if the DST rules change historically, but it does let you round-trip between timestamp and broken down local time. The fix is the DST flag. For most values stored in struct tm, the tm_isdst flag can be divined from time fields, but for the ambiguous hour this flag is necessary to read the actual time. To use mathematical analogy, tm_isdst specifies the branch of a multi-valued function. I don't advocate adding isdst flag to datetime. This solution has its own limitations and as I mentioned above, modern systems extend struct tm further adding non-standard tm_zone and tm_offset fields. What I suggest is that we skip the isdst kludge and provide a way to get system-supplied tm_zone and tm_offset to the aware datetime object. This will not solve the alarm clock problem, but will solve the what time is now and what time it was when I created this file problems. _______________________________________________ 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
