Re^5: Leap Second

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 Thompson

Comment on Re^5: Leap Second

Replies are listed 'Best First'.
Re^6: Leap Second by Perl Mouse (Chaplain) on Jan 02, 2006 at 09:00 UTC
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:>*`	[reply]
Re^7: Leap Second by swampyankee (Parson) on Jan 02, 2006 at 17:23 UTC
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]


more useful options
	PerlMonks