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 belopolsky
Recipients ajaksu2, akuchling, belopolsky, brett.cannon, doerwalter, eric.araujo, r.david.murray, tim.peters
Date 2011-05-05.17:36:34
SpamBayes Score 1.0456656e-08
Marked as misclassified No
Message-id <>
In-reply-to <>
On Thu, May 5, 2011 at 12:44 PM, R. David Murray <> wrote:
> Do you think we can get 9527 in?

I hope we can.  Pure Python implementation can be improved by deducing
the TZ offset from localtime() and gmtime() calls.  In C we can use
additional struct tm fields when they are available to do even better.
 Would you like to add your voice to support #9527?

> I'll have to keep a flag for the 60th second  outside of the datetime instance (or pretend it doesn't exist :)

If you can find an e-mail message archived somewhere with 60 seconds
in the timestamp, it will be a powerful argument to extend seconds
range that can be stored in datetime objects.   I doubt such messages
exist, though.  Few systems can produce such a timestamp even if they
happen to process an e-mail during a leap second.  In
parse_datetime(), your choice will be between raising an error and
approximating the leap second with the nearest representable time.  I
think clamping 60 seconds to 59 is the best option and this is what
datetime.fromtimestamp does if the system happens to produce a leap
second in the timetuple.
Date User Action Args
2011-05-05 17:36:35belopolskysetrecipients: + belopolsky, tim.peters, akuchling, doerwalter, brett.cannon, ajaksu2, eric.araujo, r.david.murray
2011-05-05 17:36:34belopolskylinkissue665194 messages
2011-05-05 17:36:34belopolskycreate