I think a mechanism to map solar day linked UTC with leaps to an 86400 'sec' day (which is what most people believe to be the case) to be the essential element that the original UTC authors missed. SLS seems a reasonable and simple approach. My preferred change would be 3 year leap sec notice, a name for the artificial 86400 'sec' system, and an ageed mapping between the two, such as SLS. Stephen
On 16/09/2011, Poul-Henning Kamp <[email protected]> wrote: > In message <56F8780469824813BF7CAC4E610AB561@pc52>, "Tom Van Baak" writes: > >>In a way part of the charm is that they didn't specify w. You could >>implement a leap smear on any system you choose, picking the w >>that best meets your needs. That solves the major problem with >>Markus' proposal where he uses bogus rationales to overly specify >>everything (e.g., the frequency shift must only begin at 23:43:21). > > Well, Googles hack is a workaround for internal use with no regard > to subsecond interoperability with anybody else. > > Markus proposal is for an international standard, allowing subsecond > interoperatbility at subsecond levels. > > I can fully understand Googles workaround as a way of coping with > leap seconds. > > I think Markus proposal to make them even more bizarre is a really > bad idea. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [email protected] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > LEAPSECS mailing list > [email protected] > http://six.pairlist.net/mailman/listinfo/leapsecs > _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
