[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

Guido van Rossum [EMAIL PROTECTED] added the comment: Hm, can you use lowercase for the local variable names dststart and dstend? Otherwise looks good. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2525 __

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

Daniel Diniz [EMAIL PROTECTED] added the comment: Changed the local dststart, dstend variables to lowercase, dates to times (in find start and end times) and the diff was created from trunk/ this time (as opposed to trunk/Doc/includes/). Added file:

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

Guido van Rossum [EMAIL PROTECTED] added the comment: Thanks, looks good. Since this is assigned to Georg, can you check it in, Georg? Should this be backported to 2.5 docs as well? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2525

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

Georg Brandl [EMAIL PROTECTED] added the comment: Committed as r62214, r62215 (2.5). -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2525 __

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

Daniel Diniz [EMAIL PROTECTED] added the comment: New patch. I added the new rule and changed the old behavior to be wrong (a bit) less often. It may mess with code that depended on the previous wrong results. Given the (AFAIK) exemplificative nature of this file, this should not be a big

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

Daniel Diniz [EMAIL PROTECTED] added the comment: This patch updates the behavior as per The Energy Policy Act of 2005: Start: Second Sunday in March End: First Sunday in November Time: 2 am local time -- keywords: +patch nosy: +ajaksu2 Added file:

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

Guido van Rossum [EMAIL PROTECTED] added the comment: Hi Daniel, Can you change it so that the start and end values are chosen dynamically based on the year? I.e. if year 2007 use the old values otherwise use the new ones. A tzinfo object is supposed to (within reason) handle historical

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

Daniel Diniz [EMAIL PROTECTED] added the comment: Er... 2007- : from the second Sunday in March to the first Sunday in November. :/ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2525 __

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

Changes by Daniel Diniz [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9926/tzinfo-examples.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2525 __ ___

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

Guido van Rossum [EMAIL PROTECTED] added the comment: I'd be okay with only covering 1987 and later. But it's probably good to have a table-based solution anway, to make it easy to handle future changes -- I'm sure 2007 is not the last year this is changing. :-)

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

New submission from Guido van Rossum [EMAIL PROTECTED]: The USTimeZone example class hasn't been updated for the new US DST rules that went into effect in 2007. For a description of the new rules, see: http://wwp.greenwichmeantime.com/daylight-saving-time/usa/dst-2007.htm -- assignee: