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.

Then it won't work most of the time, will it? It's only useful if you want to make a calculation in December spanning the next end of the month. It won't help you if you want to calculate what's 8 days, 12 hour, 39 minutes and 17 seconds past noon on Christmas, and you want to have the answer on Thanksgivings day. Or if you want to know what time it was 50,000 seconds ago in the morning of January 1.

There 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.

Perl --((8:>*

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