It doesn't have to. Under Unix time keeping, leap seconds don't exist. Computer clocks will have to be adjusted.
While the the whole POSIX time / leap seconds issue is a rather complicated mess (for those interested in gory details see The Future of Leap Seconds, History of IEEE P1003.1 POSIX time and Unix time) I'm not sure how it's relevant to how Date::Calc handles leap seconds?
Indeed, as documented, Date::Calc says that Time_to_Date() and Date_to_Time() take/return UTC time values that include leap seconds. The documentation appears to be lying though :-)
The leap seconds are not assigned on a regular basis. While leap years arrive predictably, leap seconds don't. The only way for a computer to know about leap seconds is to be connected to something similar to an RFC-867 time server NIST Internet Time Service. Can Date::Calc manage that? I've no clue, although there would seem to be no reason why a clever Perl programmer (i.e., not me) couldn't write Date::Calc:RFC-867 module to check for leap seconds.
emc
" When in doubt, use brute force." — Ken ThompsonThe leap seconds are not assigned on a regular basis. While leap years arrive predictably, leap seconds don't. The only way for a computer to know about leap seconds is to be connected to something similar to an RFC-867 time server NIST Internet Time Service.Well, that's not the only way. While leap seconds aren't assigned on a regular basis, they are announced way in advance, and leap seconds in the past aren't erased. A module dealing with leap seconds could just use a plain text file to store the leap seconds. A cron job to check the validity of the file run four times a year will be enough.
and leap seconds in the past aren't erased.
Leap seconds can need to be subtracted, (due to nutation?), though this is likely to occur much less frequently than their being added. It also doesn't detract from your quoted point, but does complicate things a little.
I also read(search for IERS) that leap seconds are only added on June 31st30th or December 31st, so bi-annual updates should suffice.
only added on June 31s
31 June would be a leapday, right? Guess you were thinking about 30 June, the last day of the month.
Cheers, Sören
Indeed. Thanks, corrected.
I also read(search for IERS) that leap seconds are only added on June 30th or December 31st, so bi-annual updates should suffice.But you don't want to update your lists at the times leap seconds are added (or skipped). We're talking about Date::Calc, and some people use it to calculate dates in the future. You want to update your lists as soon as it has been decided a leap second will be added or skipped. I don't know how often people meet to determine whether we'll need another leap second, but I doubt it's more often than four times a year.
A module dealing with leap seconds could just use a plain text file to store the leap seconds. A cron job to check the validity of the file run four times a year will be enough.
But where's the fun in that? More fun (this is why my kids think I'm nuts) would be to write a module to just read the RFC-867 data from the NIST Internet Time Service and do it automatically.
I just think it would take a Perlist who is either better than I am or has more free time. Preferably both. Any volunteers?
emc
" When in doubt, use brute force." — Ken ThompsonBut where's the fun in that?The fun is disproving that your statement The only way for a computer to know about leap seconds ... is false.
More fun (this is why my kids think I'm nuts) would be to write a module to just read the RFC-867 data from the NIST Internet Time Service and do it automatically.How would you actually do that? RFC-867 seems to be a protocol to send the current time - how would you use that to determine when leap seconds have happened? Even if you'd now start querying the server every second to determine a possible leap second, it wouldn't really help Date::Calc - you have no information about leap seconds in the past, nor about any upcoming leap seconds.
The package definition used by NIST (apparently RFC-867 doesn't define the packet very well) includes a flag which inidicates whether a leap second will be added or subtracted at the end of the month."L is a one-digit code that indicates whether a leap second will be added or subtracted at midnight on the last day of the current month. If the code is 0, no leap second will occur this month. If the code is 1, a positive leap second will be added at the end of the month. This means that the last minute of the month will contain 61 seconds instead of 60. If the code is 2, a second will be deleted on the last day of the month. Leap seconds occur at a rate of about one per year. They are used to correct for irregularity in the earth's rotation. The correction is made just before midnight UTC (not local time)." Since the leap second correction is always (with NIST) on the last day of the month, it would really only be necessary to check sometime before midnight on the last day of the month.
emc
" When in doubt, use brute force." — Ken ThompsonThere have been 23 leap seconds since 1972. For Date::Calc style calculations, you need to know all of them. At any moment. Just knowing whether there will be one at the end of the current month won't do.
For the first part: true, within the limits of RFC-867 as implemented by NIST.
For the second: the list of past leap seconds is known, and universal. Much more difficult to modify Date::Calc to be useful before the Julian to Gregorian calendar change overs (which, as I'm sure you know, varied by the countries extant at the time).
It's a separate question as to whether someone would want to allow for leap seconds or not, which is why I suggested (semi-seriously) Date::Calc::RFC-867. It can be done, within limits. Date::Calc does have admitted limits; it can't give me the date for Easter before 1583 (say, I want to answer the question: "How many solar eclipses visible in Europe fell on Easter?"). So, as a sensible programmer, I realize I can't use Date::Calc to answer that question. If I want to know on Nov 30, 2005-- using just the information available from NIST's implementation of RFC-867 -- what time it was 8 days, 3 hours, 44 minutes, 16 seconds before noon on Jan 1, 2006 -- I'd have to allow for the fact the time calculated on Dec 1, 2005 may be a second different. Incidentally, I'm not proposing, in any manner, that the current functionality of Date::Calc be modified. Some users may find an RFC-867 extension to be useful, but modifying the way Date::Calc works currently would probably break far too many programs. The current changes to the US DST rules are going to cause enough disruption, as it is.
emc
" When in doubt, use brute force." — Ken Thompson