On Tue, Jun 17, 2003 at 08:58:54PM -0400, Matthew Donadio wrote:
John Meacham wrote:
UNIX hacks around this by changing the length of a second around a leap second, so every timestamp when interpreted as an offset from epoch without any leap seconds (i.e. every minute is 60 seconds) is correct, but the tradeoff is that the length of a second is no longer defined and you can't do time arithmetic or time offsets correctly.
Are current libraries really this brain dead? I haven't dealt with time in almost 10 years, and always had very strict requirements (timetaging satellite telemetry). Sloppiness like that really surprises me.
yup. unfortunatly this brokenness is mandated by POSIX: POSIX.1 defines seconds since the Epoch as a value to be interpreted as the number of seconds between a specified time and the Epoch, according to a formula for conversion from UTC equivalent to conversion on the na basis that leap seconds are ignored and all years divisible by 4 are leap years. This value is not the same as the actual number of seconds between the time and the Epoch, because of leap seconds and because clocks are not required to be synchronised to a standard reference. The intention is that the interpretation of seconds since the Epoch values be consistent; see POSIX.1 Annex B 2.2.2 for further rationale. the only way to reconcile the POSIX time with real time is by changing the speed of the clock and hence the length of a POSIX second. even worse, POSIX got the formula for leap years wrong so you have to make up for a whole day at times (!!) (if you follow the standard exactly, the leap year problem is considered a typo by many). in any case, anyone who wants accurate times uses an alternate library such as djb's libtai or rolls their own solution. Using TAI internally and only dealing with UTC when translating between CalendarTimes has a number of advantages, CalendarTime already has a timezone field, so it is not even that odd to expect it to translate the time to UTC if that "timezone" is specified. TAI is well defined for arbitrary times in the past, using an 'Integer' means we can represent times accuratly across all of history and the future. :) This makes the native Time type in haskell suitable for actual scientific work, which is good. the only source of confusion I can think of is if the Integer representing TAI relative to epoch is misinterpreted as a time_t equivalent under POSIX, providing toPosixUTC :: ClockTime -> Integer and fromPosixUTC :: Integer -> ClockTime would be useful and advisable John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------