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. 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 Thompson
| [reply] |
| [reply] |
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
| [reply] |