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-07-19.16:42:16
SpamBayes Score 0.000688437
Marked as misclassified No
Message-id <>
After reading the new wording on a formatted page, I don't like the proposed changes:


When daylight is nonzero, altzone specifies the offset of the local DST timezone, in seconds west of UTC. This is negative if the local DST timezone is east of UTC ...

In the second sentence, it is not clear whether "this" refers to altzone or daylight.


Whether or not DST is in effect, daylight specifies the DST offset. 

This is simply wrong.  time.daylight does not necessarily specify the DST offset (and I think it does not on most systems.)  POSIX requires that "The tzset() function also shall set the external variable daylight to 0 if Daylight Savings Time conversions should never be applied for the timezone in use; otherwise, non-zero." [1]  This means that a compliant system may store just 0 or 1 in daylight rather than the DST offset.

For example, on my OSX system:

$ TZ=America/New_York python -c "import time; print(time.daylight)"
$ TZ=UTC python -c "import time; print(time.daylight)"
$ TZ=EDT python -c "import time; print(time.daylight)"

I will think some more on how to improve the current documentation, but at least with respect to time.daylight, current language is better than the proposed change.

Date User Action Args
2010-07-19 16:42:18belopolskysetrecipients: + belopolsky, georg.brandl, techtonik, brian.curtin, napik, docs@python
2010-07-19 16:42:18belopolskysetmessageid: <>
2010-07-19 16:42:17belopolskylinkissue7229 messages
2010-07-19 16:42:16belopolskycreate