Alexander Belopolsky <[email protected]> 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 <[email protected]>
<http://bugs.python.org/issue7229>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
