[LEAPSECS] leap smear

[Stephen Colebourne]

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 <phk at phk.freebsd.dk> wrote:

> In message <56F8780469824813BF7CAC4E610AB561 at 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

> phk at FreeBSD.ORG         | 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

> LEAPSECS at leapsecond.com

> http://six.pairlist.net/mailman/listinfo/leapsecs

>