Issue626570
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.
Created on 2002-10-21 21:59 by otterley, last changed 2022-04-10 16:05 by admin. This issue is now closed.
Messages (6) | |||
---|---|---|---|
msg12897 - (view) | Author: Michael S. Fischer (otterley) | Date: 2002-10-21 21:59 | |
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' |
|||
msg12898 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2002-10-21 23:34 | |
Logged In: YES user_id=33168 Michael, what version(s) of Python does this effect? 2.2.2? 2.3? |
|||
msg12899 - (view) | Author: Michael S. Fischer (otterley) | Date: 2002-10-21 23:43 | |
Logged In: YES user_id=7820 I've seen it in 1.5.2, 2.1.3, 2.2 and 2.2.1. |
|||
msg12900 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2002-10-22 22:42 | |
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. |
|||
msg12901 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2002-11-02 20:03 | |
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. |
|||
msg12902 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2002-11-12 23:16 | |
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. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:05:46 | admin | set | github: 37356 |
2002-10-21 21:59:58 | otterley | create |