[LEAPSECS] stale leap second information

[Zefram]

Tom Van Baak wrote:
>There must be thousands of source files with stale leap second tables
...
>Is there any solution to this?

For those who think ahead, the obvious solution is that every leap second
table (hard-coded or otherwise) must include data showing the limits of
its validity, and all code using a leap second table must signal an error
if it attempts a conversion that falls outside the table's validity.
My Perl module Time::UTC does this, progressively falling back from
its hard-coded table to dynamically downloading a table to refusing
conversion entirely:

$ time perl -MTime::UTC=utc_ymdhms_to_instant,utc_to_tai -Mbigrat -lwe 'print &utc_to_tai(utc_ymdhms_to_instant(2010,1,1,0,0,0))'
1640995234
0.15s user 0.01s system 97% cpu 0.164 total
$ time perl -MTime::UTC=utc_ymdhms_to_instant,utc_to_tai -Mbigrat -lwe 'print &utc_to_tai(utc_ymdhms_to_instant(2015,1,1,0,0,0))'
1798761635
0.18s user 0.02s system 24% cpu 0.826 total
$ time perl -MTime::UTC=utc_ymdhms_to_instant,utc_to_tai -Mbigrat -lwe 'print &utc_to_tai(utc_ymdhms_to_instant(2016,1,1,0,0,0))'
day 21184 has no UTC definition yet at -e line 1.
0.20s user 0.02s system 25% cpu 0.832 total

(The "total" times reveal which runs downloaded a table.)

Where authors haven't so thought ahead, there's no way to avoid code
producing the wrong answer.  I'm inclined to take a hard line, by treating
the willingness to perform incorrect conversions as a reportable bug.
When I raised this issue with respect to the Perl module DateTime,
I got back a somewhat fanciful suggestion that the bug isn't so much
treating the leap table as complete but that the table is actually
incomplete, meaning that the code is permanently buggy but the bug
for any particular future date will be fixed in some future version.
<http://www.nntp.perl.org/group/perl.datetime/2006/07/msg6367.html>

One of the problems with such incomplete leap tables, beyond
conversions being incorrect, is that conversions are inconsistent
between different programs, and between different versions of the
same program.  With DateTime it turned out that what was supposedly a
single version actually embedded two different leap tables, and which
one it would use depended on an accident of installation.  (One table
in the Perl code, and one in the C code that's preferred for speed.)
<http://www.nntp.perl.org/group/perl.datetime/2008/10/msg7081.html>

-zefram