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 techtonik
Recipients belopolsky, docs@python, georg.brandl, napik, techtonik
Date 2011-01-11.21:14:17
SpamBayes Score 4.27804e-11
Marked as misclassified No
Message-id <>
In-reply-to <>
On Tue, Jan 11, 2011 at 4:52 PM, Alexander Belopolsky
<> wrote:
> ..
>> -  Nonzero if a DST timezone is defined.
>> + .. To check if DST is currently active, use `time.localtime(t).tm_isdst`
> This is simply wrong. Your time.localtime(t).tm_isdst expression will
> return the DST flag for the POSIX time value t, not for the current
> time.  This could be fixed by replacing your proposed expression with
> time.localtime().tm_isdst, but why do you think someone  reading about
> time.daylight actually wants to "check if DST is currently active"?

Sorry, I've just copy/pasted this snippet and haven't noticed t argument.

As for your question, I think that someone reading about time.daylight
is reading about it to know how it can be used, and if you're quoting,
please quote without removing words inside the quote, or else I won't
be able to give you the answers that will be appropriate in your

> What can be improved, though, is the documentation of time.tzset().
> The current version fails to mention that  time.tzset() resets the
> values of tzname, timezone, altzone and daylight.  This would be the
> proper place to document the meaning of all three variables in greater
> detail.  Individual entries can then refer to it with say "See
> time.tzset() for details."

How about making it in iterations and keep the steps as small as
possible, i.e. split the big problem into munchable chunks? First we
can accept the version of doc from my previous comment and then open a
new RFE for further work. Considering how much time this issue took
already, I see this approach as the only viable one.

> Here is how POSIX tzset() is defined:
> ...

I am sorry Alexander, but I can't really follow up on this issue. It
is interesting, but unfortunately right now I can only dedicate my
time to things that take don't more than 15 minutes of my attention,
and there are about 50 out of 700 of these in my inbox right now. We
need to split these datetime problems into smaller ones somehow. They
are really too complex for users.

To summarize: What is wrong with my previous proposal if we remove t
from params?

P.S. Looks like we need a PEP for this. =)
Date User Action Args
2011-01-11 21:15:00techtoniksetrecipients: + techtonik, georg.brandl, belopolsky, napik, docs@python
2011-01-11 21:14:17techtoniklinkissue7229 messages
2011-01-11 21:14:17techtonikcreate