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 lemburg
Recipients georg.brandl, lemburg, loewis, luckmor
Date 2009-01-01.21:39:50
SpamBayes Score 7.617756e-08
Marked as misclassified No
Message-id <495D3825.7090100@egenix.com>
In-reply-to <1230706101.54.0.711688688948.issue4775@psf.upfronthosting.co.za>
Content
FWIW: POSIX defines Unix time_t *not* to include leap seconds.

You can easily check whether your platform or C lib behaves
POSIX-ly correct or not:

   POSIX: 1986-12-31 23:59:59 UTC == 536457599 ticks

   With leap seconds:		  == 536457612 ticks

   (since there were 13 leap seconds in the years 1972-1985)

For most practical purposes the difference doesn't really matter,
since date differences are usually counted in days, not seconds.

In cases where it does matter, you're better off with a custom
solution, since applications or other libraries tend not to handle
leap seconds well.
History
Date User Action Args
2009-01-01 21:39:52lemburgsetrecipients: + lemburg, loewis, georg.brandl, luckmor
2009-01-01 21:39:51lemburglinkissue4775 messages
2009-01-01 21:39:50lemburgcreate