[Python-bugs-list] [ python-Bugs-626570 ] strptime() always returns 0 in dst field

[noreply@sourceforge.net]

Bugs item #626570, was opened at 2002-10-21 17:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626570&group_id=5470

Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Michael S. Fischer (otterley)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: strptime() always returns 0 in dst field

Initial Comment:
time.strptime() has always returned 0 in the Daylight
Savings Time flag of the returned tuple.

This leads to nasty bugs like the "off by an hour" bug
revealed below:

>>> strftime("%Y %b %d %H %M %S %Z",
                localtime(int(mktime(strptime("Oct 18
2002 00:00:00", "%b %d %Y %H:%M:%S")))))
'2002 Oct 18 01 00 00 PDT'




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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-11-12 18:16

Message:
Logged In: YES 
user_id=33168

Michael, I'm closing this as "Won't Fix."  I agree there is
a problem in 2.2.x, but I don't believe this is possible to
fix without creating backwards compatibility problems.  As I
mentioned earlier, this is fixed in 2.3.  If you would like
to discuss this further, please send mail to
python-dev@python.org.

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

Comment By: Brett Cannon (bcannon)
Date: 2002-11-02 15:03

Message:
Logged In: YES 
user_id=357491

I think Neal is right in thinking that changing this might break backwards 
compatibility.  If someone stored timestamps as the tuples directly and 
then suddenly the new timestamps for something started having a 
different dst value all the calculations comparing new and old will be off 
if they use the dst flag.  This tends to be a bad thing when changing 
between dot releases.

Besides, if the DST flag is that important it should have been specified 
in the string passed to strptime().  Otherwise strptime has to just 
assume there is none (like in 2.2), or guess (like in 2.3).  You are 
basically paying the price for wanting strptime() to infer what you want 
dst to be.  The docs also say that you are at the mercy of the underlying 
C library and there is a lot of variety for strptime() since it is not a part of 
ANSI C.

In other words, I say this is all a moot point.  If accurate timing is that 
important use UTC timestamps.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-10-22 18:42

Message:
Logged In: YES 
user_id=33168

I'll have to look at this more.  With 2.3, I get 00 00 00,
with 1.5.2, 2.1.1, and 2.2.2, I get 01 00 00.

The difference seems to be that the tm_isdst flag is set to
-1 (mktime should guess) in 2.3, but the flag is set to 0 in
other versions.

It's possible this bug may not be able to be fixed due to
backwards compatibility.

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

Comment By: Michael S. Fischer (otterley)
Date: 2002-10-21 19:43

Message:
Logged In: YES 
user_id=7820

I've seen it in 1.5.2, 2.1.3, 2.2 and 2.2.1.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-10-21 19:34

Message:
Logged In: YES 
user_id=33168

Michael, what version(s) of Python does this effect?  2.2.2?
 2.3?

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

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