[Python-bugs-list] [ python-Bugs-675222 ] time.daylight badly defined

SourceForge.net noreply@sourceforge.net
Sun, 26 Jan 2003 21:02:50 -0800


Bugs item #675222, was opened at 2003-01-26 22:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675222&group_id=5470

Category: Documentation
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Tim Peters (tim_one)
Summary: time.daylight badly defined

Initial Comment:
'Nonzero if a DST timezone is defined' is meaningless if the timezone automatically switches into DST.

A better definition might be 'Nonzero if the current local time is in DST'

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-01-27 00:02

Message:
Logged In: YES 
user_id=31435

I don't think any standard requires that the two tznames 
differ if a time zone has a notion of daylight time.  I know 
that Brett Cannon got in trouble with the 2.3a1 all-Python 
strptime() implementation simply for assuming that at least 
one tzname value wasn't an empty string!  The perversity of 
OSes is (unfortunately) unbounded here -- and ANSI C 
refused to standardize any of the time zone stuff.

----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-01-26 23:42

Message:
Logged In: YES 
user_id=46639

So it would be fair to say

	daylight == (tzname[0] != tzname[1]) 

If so, this makes it easier on me and is actually testable behavior :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-26 23:32

Message:
Logged In: YES 
user_id=31435

"daylight" was originally defined by X/Open, and taken over 
by POSIX.  Python defines it the same way they do.  It's 
not there to tell you whether it's *currently* daylight saving 
ime (get a struct tm for the time you're interested in and 
look at tm_isdst for that), it's only there to tell whether 
time.altzone should be used when tm_isdst is > 0.

The SCO docs are clearer than most on these points:

http://osr5doc.ca.caldera.com:457/cgi-bin/man/man?
ctime+S

but note that the tm_tzadj and tm_name documented there 
are non-portable extensions.

C's time zone facilities are a x-platform mess, but I expect 
you're figuring that out <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675222&group_id=5470