This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, brian.curtin, docs@python, georg.brandl, napik, techtonik
Date 2010-06-05.16:32:17
SpamBayes Score 0.0026173869
Marked as misclassified No
Message-id <1275755540.13.0.788880042553.issue7229@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-06-05 16:32:20belopolskysetrecipients: + belopolsky, georg.brandl, techtonik, brian.curtin, napik, docs@python
2010-06-05 16:32:20belopolskysetmessageid: <1275755540.13.0.788880042553.issue7229@psf.upfronthosting.co.za>
2010-06-05 16:32:18belopolskylinkissue7229 messages
2010-06-05 16:32:17belopolskycreate