[LEAPSECS] UTC fails

[Warner Losh]

> On Mar 13, 2015, at 12:57 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
> On 12 March 2015 at 05:21, Steve Allen <sla at ucolick.org> wrote:
>> On Wed 2015-03-11T11:04:57 -0700, Tom Van Baak hath writ:
>>> The entire purpose of UTC is to provide a single timescale for all
>>> human-related activity.
>> 
>> And UTC has failed miserably.  POSIX says UTC has no leaps.
>> Google says UTC has occasional days with stretches of seconds which
>> are of varying lengths.  De facto, there is no single UTC time scale.
> 
> But what so many miss is that what is needed to fix the problem is very small.

Except that it isn’t.

> 1) Reliably send leap second data out to the world (recently discussed
> here and at tz-dist)

Doesn’t fix the POSIX time_t issue.

> 2) Announce leap seconds a bit further in advance or on a regular schedule

Ditto.

> 3) Define a time-scale, UT-86400, that roughly follows UTC but always
> has 86400 "second-like" subdivisions (as per the Java time-scale)
> 
> 4) Provide one or more *agreed* and *standardised* mechanisms to map
> UTC to UT-86400 (eg. UTC-SLS and Google smear)

So UTC is great, except that we need to do this other thing that isn’t
UTC because UTC isn’t great? Seems like a lot of effort when dropping
leap seconds is a lot easier to implement.

> The fact that we don't have a name or agreed standard for the thing
> that most people want (outside the time-nerd community) is very sad.
> UT-86400 is a working name, I'm sure someone can think of a better
> one.
> 
> The work needed isn't hard. I just wish that rather than destroying a
> sensible solution to keep us in line with solar days, effort would be
> put into defining the above.

So why is keeping us inline with solar days so desirable? The rate of
change is so slow and the number of people already out of sync with
solar time on the second level is so large it seems like a lot of hassle
for not much benefit when DUT1 can be known. Apart from telescopes,
nothing really breaks.

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20150313/a49b7750/attachment.pgp>