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 tim.peters
Recipients
Date 2002-03-27.04:14:22
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=31435

Guido, I just want to be clear that the OP is fighting the 
bad effects of leap seconds too.  Leap seconds are part of 
the definition of UTC, but not part of the OP's preferred 
TAI.

POSIX mandates that time_t <-> struct tm conversions be 
computed as if every day had 86400 seconds, but because 
people using NTP (or other sync services) end up having 
clocks displaying UTC, the POSIX standard is forced to add:

"The relationship between the actual time of day and the 
current value for seconds since the Epoch is unspecified."

IOW, POSIX defines localtime() in such a way that there's 
no defined relationship between time_t values and what a 
box believes the time is.

I think POSIX gave up too easily here -- the result is 
unusable for many purposes.  So I sympathize w/ the OP.  At 
the same time, it's not Python's job to repair POSIX's 
shortcomings, and the POSIX rules are at least platform-
independent and predictable.
History
Date User Action Args
2007-08-23 13:58:25adminlinkissue497162 messages
2007-08-23 13:58:25admincreate