RE: [LEAPSECS] two world clocks

From: Seeds, Glen <Glen.Seeds_at_Cognos.COM>
Date: Mon, 24 Jan 2005 09:59:22 -0500

I hadn't seen this before - thanks. It doesn't surprise me, though.
Unless I'm missing something, getting replacing leap seconds with leap
hours (r leap-anything related of the length of a day) would not
simplify any of this. The only way to simplify it is to remove the
ability to adjust for day length altogether. This voids the whole
purpose of UTC, and we might as well just go to TAI. Given the
discussion we've seen, I doubt that would meet with general approval.

My claim is that there are very few applications in the world that
really need something like this longtime API. I've heard a few
speculated about (e.g. legal contracts), but none I've seen stand up
under scrutiny. Do you know of any?

  /glen

> -----Original Message-----
> From: Leap Seconds Issues [mailto:LEAPSECS_at_ROM.USNO.NAVY.MIL]
> On Behalf Of Poul-Henning Kamp
> Sent: January 21, 2005 10:46 AM
> To: LEAPSECS_at_ROM.USNO.NAVY.MIL
> Subject: Re: [LEAPSECS] two world clocks
>
> In message
> <9BFB7804FD3C2E498082D60C3B80BC79010E6646_at_sottemail2.ent.ad.cognos.c
> om>, "Seeds, Glen" writes:
>
> >This was not an oversight. Considerable analysis went into
> >understanding how this would work. The bottom line is that
> it's not a
> >problem for all but a very few applications, which have ways to work
> >around it. These same applications have timekeeping synchronization
> >costs that are far larger than the costs of these workarounds.
>
> One of the better arguments for getting rid of leapseconds is
> seen by printing this page:
>
> http://david.tribble.com/text/c0xlongtime.html
>
> And then marking all the stuff that would not be necessary
> and remove all the support for optionally represented leapseconds.
>
> There is a lot less left afterwards.
>
> --
> 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.
>
>
>

       This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.
Received on Mon Jan 24 2005 - 06:59:44 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT