[LEAPSECS] a modest proposal

[Magnus Danielson]

From: Tony Finch <dot at dotat.at>
Subject: Re: [LEAPSECS] a modest proposal
Date: Mon, 11 Feb 2008 13:31:17 +0000
Message-ID: <alpine.LSU.1.00.0802111310040.14814 at hermes-1.csi.cam.ac.uk>


> On Sat, 9 Feb 2008, Steve Allen wrote:

> >

> > I think that POSIX time_t should be redefined to be TI, with no leap

> > seconds.  I think that the leap seconds should be included in the

> > zoneinfo files.  POSIX already allows that the local time can be

> > offset by an arbitrary number of seconds (not just hours and minutes)

> > from the system value of time_t.  The mechanism by which this is

> > communicated to POSIX systems is zoneinfo.  The zoneinfo maintainers

> > are accustomed to making changes many times a year, with almost no

> > advance notice, subject to whims of political entities which are

> > much less predictable than leap seconds.

> >

> > This keeps the simplicity of POSIX system time with the only cost

> > being one of interpretation: the system time_t is TI, and UTC be an

> > entity derived using zoneinfo.

> 

> This is quite an attractive idea. I wonder how to deal with some of the

> consequences:

> 

> How should the kernel interpret time stamps stored in filesystems? Do you

> propose to retrospectively re-interpret them as being in TI instead of

> POSIX time? (This is related to the problem that Unixes have with FAT

> filesystems that store timestamps in some unspecified local time, which

> implies that the kernel can't be ignorant of local time.)

> 

> How do you cope with programs that assume that POSIX time is UTC, and

> which therefore bypass the tz code when handling UTC timestamps?

> 

> How do you represent TI textually? i.e. how should ISO 8601 be revised?


The trouble with this proposal is that "TI" will in a few years time be as
arbitrary as "TAI" with the only major difference is the magical 33 or 34
second offset. It would be much more sensible to use TAI directly IMHO.

The ISO 8601 problem would be the same thought.


> How does this affect NTP, which uses a POSIX-like timescale?


NTP would require to support both UTC and TAI/TI to be usefull, else we have
to toss NTP over the shoulder and start from the beginning.

Cheers,
Magnus