On 26 January 2005 21:27, Peter Simons wrote:
Marcin 'Qrczak' Kowalczyk writes:
23:59:60
[...] and UTC doesn't have leap seconds.
Just a minor point ... it does, see above. ;-) I'm not sure how the loss of a second would be expressed, though.
This is quite a subtle point. What people have been referring to as "UTC seconds" I would call time_t. time_t does not include leap seconds in its count; rather the actual duration of a second gets longer around a leap second. UTC is a calendar in which some minutes have 61 seconds. My library in fact maps both seconds to 23:59:59 at a leap second:
let t = CalendarTime{ ctYear=1998, ctMonth=11, ctDay=31, ctHour=23, ctMin=59, ctSec=59, ctPicosec=0, ctTZ=utcTimezone } clockTimeToUTCTime (fromJust (calendarTimeToClockTime t)) Thu Dec 31 23:59:59 UTC 1998 clockTimeToUTCTime (fromJust (calendarTimeToClockTime t) + 10^12) Thu Dec 31 23:59:59 UTC 1998 clockTimeToUTCTime (fromJust (calendarTimeToClockTime t) + 2*10^12) Fri Jan 1 00:00:00 UTC 1999
(adding 10^12 for a second because ClockTime is measured in picoseconds). Cheers, Simon
In article
<3429668D0E777A499EE74A7952C382D1031137AF@EUR-MSG-01.europe.corp.microso
ft.com>,
"Simon Marlow"
This is quite a subtle point. What people have been referring to as "UTC seconds" I would call time t. time t does not include leap seconds in its count; rather the actual duration of a second gets longer around a leap second.
Yes. Unlike UTC, TAI etc., time_t is ambiguous at leap seconds. Even knowing when leap seconds occur, we can't perfectly convert time_t to UTC or TAI. Unfortunately time_t is what gettimeofday and the other system calls return.
UTC is a calendar in which some minutes have 61 seconds.
My library in fact maps both seconds to 23:59:59 at a leap second:
The alternative would be to allow ctSec to go up to 60. I prefer a (days,ticks) format for representing UTC rather than CalendarTime, but either way, it ought to be possible to represent UTC unambiguously even if time from the system clock is broken. That way we play well with someone else's better clock function. -- Ashley Yakeley, Seattle WA
participants (2)
-
Ashley Yakeley -
Simon Marlow