[issue7229] Manual entry for time.daylight can be misleading
anatoly techtonik <techtonik@gmail.com> added the comment: It is too hard to track this issue without quotes from manual. Let's bring context into discussion: http://docs.python.org/library/time.html#time.altzone UTC offset of the local DST timezone if one is defined. Only use this if daylight is nonzero. http://docs.python.org/library/time.html#time.daylight Nonzero if a DST timezone is defined. http://docs.python.org/library/time.html#time.timezone UTC offset of the local (non-DST) timezone So, to answer a question "What is the current UTC offset?" you need to: if time.daylight: if time.altzone: # using only if defined use time.altzone else: use time.timezone else: use time.timezone 1. Is that really works like described above? 2. Should we at least group these timezone variables? As for offtopic UTC vs GMT - I doubt there is a way to clearly express that the offset sign of the returned values is negated in comparison with real "UTC offsets" without resorting to some king of alternative east/west scale. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue7229> _______________________________________
Alexander Belopolsky <belopolsky@users.sourceforge.net> added the comment: On Sat, Jun 5, 2010 at 1:24 PM, anatoly techtonik <report@bugs.python.org> wrote: ..
As for offtopic UTC vs GMT - I doubt there is a way to clearly express that the offset sign of the returned values is negated in comparison with real "UTC offsets" without resorting to some king of alternative east/west scale.
Sure there is. Here is how RFC 3339 handles this: """ Numeric offsets are calculated as "local time minus UTC". So the equivalent time in UTC can be determined by subtracting the offset from the local time. """ and here is a quote from MacOS man page for tzset: """ offset Indicates the value one must add to the local time to arrive at Coor- dinated Universal Time. """ No geographic reference needed. (And the issue is not UTC vs. GMT: both UTC and GMT are timescales, sometimes even considered the same. The off-topic issue is UTC vs. Prime Meridian.) ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue7229> _______________________________________
Alexander Belopolsky <belopolsky@users.sourceforge.net> added the comment: On Sat, Jun 5, 2010 at 1:24 PM, anatoly techtonik <report@bugs.python.org> wrote: ..
So, to answer a question "What is the current UTC offset?" you need to: if time.daylight: if time.altzone: # using only if defined use time.altzone else: use time.timezone else: use time.timezone
No, if time.daylight is non-zero, you still need to check the current value of tm_isdst from localtime(). Here is how bzr reportedly handles this: def local_time_offset(t=None): """Return offset of local zone from GMT, either at present or at time t.""" # python2.3 localtime() can't take None if t is None: t = time.time() if time.localtime(t).tm_isdst and time.daylight: return -time.altzone else: return -time.timezone http://blogs.gnome.org/jamesh/2006/12/31/python-timetimezone-timealtzone-edg...
1. Is that really works like described above?
That works for current time, but subject to race condition twice a year. You should get time and dst indormation from the same localtime() call. For problems with arbitrary time t, see the link above.
2. Should we at least group these timezone variables?
The come from existing C library practice. POSIX defines tzname[2], timezone, and daylight. http://www.opengroup.org/onlinepubs/009695399/basedefs/time.h.html altzone is a popular non-standard addition which is strictly redundant. Since POSIX does not define anything about daylight variable other than it has to be zero when DST is not in effect, compliant implementations can define is so that altzone = timezone - daylight. These variables are already grouped in tzinfo API. What is missing is method to get concrete tzinfo implementation in stdlib. See issue5094. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue7229> _______________________________________
participants (2)
-
Alexander Belopolsky -
anatoly techtonik