Merely a datum, not a proof-of-correctness... [[ The grammar element time-second may have the value "60" at the end of months in which a leap second occurs -- to date: June (XXXX-06- 30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see Appendix D for a table of leap seconds. It is also possible for a leap second to be subtracted, at which times the maximum value of time-second is "58". At all other times the maximum value of time-second is "59". Further, in time zones other than "Z", the leap second point is shifted by the zone offset (so it happens at the same instant around the globe). ]] -- http://www.ietf.org/rfc/rfc3339.txt #g -- At 09:46 27/01/05 +0000, Simon Marlow wrote:
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 _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
------------ Graham Klyne For email: http://www.ninebynine.org/#Contact