Zefram <zef...@fysh.org> wrote: > Rob Seaman wrote: >> I'm very much enjoying the dueling perl / python and CRC / SHA competition >> here :-) > > Perl vs Python is of no significance. I use Perl for my example code > merely because it's more familiar to me; the same algorithms can be coded > either way. CRC vs SHA is of slightly greater significance (see below).
We want interoperating implementations. SHA support is straightforward in Python, too. It seems entirely reasonable to use zefram's magic numbers and whatever message digest is deemed "best" these days to deliver however many nibbles of hash are needed for each application. > The way to deal with that is to also have an AAAA encoding from day one. The > AAAA encoding can trivially have a much bigger range, such as 32 bits for > offset. Yes, but we might also want to use the extra space to support additional features. This would also encourage switching to AAAA. We appear to have all the ingredients at hand, now. The question returns to the use cases we want to emphasize. It seems to me that Bulletin C remains central, but there's no reason others can't also be supported. An alternate formulation might be to query when_is_the_next.leapsec.com to return a date, and then convert that date to july2015.leapsec.com to retrieve the new value and flags. Is there some obvious advantage (other than the bigger ranges) for separating the two values? Rob _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
