[docs] [issue7229] Manual entry for time.daylight can be misleading

Alexander Belopolsky report at bugs.python.org
Sat Jun 5 18:32:21 CEST 2010

Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It may be a bit off-topic for this issue, but I don't like that the python manual uses UTC as if it was a geographical location.  UTC is a time scale.  You cannot be to the east or to the west of UTC just as you cannot be to the north of the Gregorian calendar.

Even if we replace UTC with Prime or Greenwich Meridian, the manual would still be incorrect because some regions in the western hemisphere use positive offsets from UTC.  For example, Madrid is at 3° 42' West, but uses Central European Time which is UTC+1.

Since there are no plans to include any kind of geographical database in  the standard library, I think the manual should avoid use of geographical terms.

What I need to know from the manual is how to get local time from utc and daylight savings time from the standard time.

>From the top of my head, I know that localtime = utctime + utcoffset, but I am not sure whether dsttime = stdtime + dst or dsttime = stdtime - dst and the manual, reworded or not, does not immediately help me.

As for the original issue, do we really need time.daylight at all?  ISTM that in timezones without DST, time.altzone = time.timezone, so the software that unconditionally accounts for DST will still work correctly and software that wants to optimize for no DST case can simply chsck time.altzone == time.timezone.

$ TZ=UTC ./python.exe -c "import time; print(time.daylight, time.tzname, (time.timezone, time.altzone))"
0 ('UTC', 'UTC') (0, 0)

In other words, time.daylight is strictly redundant.


Python tracker <report at bugs.python.org>

More information about the docs mailing list