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 <BANLkTinYLKrCsXtQ2QLxSRQJeZe5usHDew@mail.gmail.com>
In-reply-to <1304613844.27.0.243381227381.issue665194@psf.upfronthosting.co.za>
Content
On Thu, May 5, 2011 at 12:44 PM, R. David Murray <report@bugs.python.org> 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.
History
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