[LEAPSECS] stale leap second information

[Rob Seaman]

Warner,

Is this what you meant?

	% dig +short jun.2009.leapsec.com txt
	"2009-06-30T23:59:59Z”

I don’t want to invest the time typing two entries per year for the past four decades into the rather constrained web interface if this isn’t the concept ;-)

(Hmm…looks like I can upload a file from another drop-down, but still…)

At any rate we should try some variations just to see how they will function in practice.  That is, will applications want to retrieve the entire list as with Tony’s example, or query a specific leap-second opportunity?  And should the format be an explicit ISO-8601 timestamp, or a yes/no flag, or a count from some epoch, or +1 / 0 / -1 flag, or what?  If a txt record there is plenty of room for (perhaps) comma separated fields of DUT1, a CRC, what-have-you.  If an a or aaaa record there are greater constraints but perhaps more direct access to hex breakdown of the fields.  Etc and so forth.

Rob
—

Tony’s version is there, too:

% dig +short leapsec.com aaaa

1973:12:31::23:59:60
1990:12:31::23:59:60
1989:12:31::23:59:60
1987:12:31::23:59:60
1985:6:30::23:59:60
1983:6:30::23:59:60
1982:6:30::23:59:60
1981:6:30::23:59:60
1979:12:31::23:59:60
1978:12:31::23:59:60
2012:6:30::23:59:60
2008:12:31::23:59:60
2005:12:31::23:59:60
1998:12:31::23:59:60
1997:6:30::23:59:60
1995:12:31::23:59:60
1994:6:30::23:59:60
1993:6:30::23:59:60
1992:6:30::23:59:60
1977:12:31::23:59:60
1976:12:31::23:59:60
1972:6:30::23:59:60
1972:12:31::23:59:60
1974:12:31::23:59:60
1975:12:31::23:59:60
2015:6:30::23:59:60