[LEAPSECS] presentations from AAS Future of Time sessions

Magnus Danielson magnus at rubidium.dyndns.org
Fri Jan 10 21:23:55 EST 2014


On 10/01/14 20:08, Harlan Stenn wrote:

> Warner Losh writes:

>> ...

>>

>> A TAI realization of time_t isn't POSIX, which specifically proscribes

>> UTC.

>

> I think you mean "prescribes".


Regardless, today the POSIX standard has a mapping (or used to, last
time I checked I was unable to find that mapping, they seem to have lost
the reference to the motivation chapter) from UTC to time_t.
Warner should remember that I do know this, so what I wrote was just
"this is the way I would hack it".

If you want the time_t to be simplified you either do that mapping from
TAI or UTC, and doing it from TAI has the benefit of providing a
continuous time over leap-second insertions.

What I proposed as an concept idea have a number of different concerns
in them:

* Most POSIX usages still don't require *real* UTC, but want a simple
"linear" scale which kinda looks like normal time.

* Breaking the normal interface for apps which doesn't really care fills
no purpose.

* That applications that care about proper UTC or proper local-time
needs fixing require an additional interface might be feasible to get
accepted rather than pulling the rug from underneath everything.

* TAI and UTC has a well understood relationship such that you can
convert between them given complete time-stamp and know which time-scale
they are in.

* Using TAI from mapping into time_t provides a non-ambigous
bidirectional mapping. The issue occurs when mixing TAI and UTC based
time_t in a dataset.

* For most usage, UTC or local time is a presentation issue.

This is orthogonal to the proposal of having 10 years irrevocable notice
of leapseconds, which addresses another problem in the mix. I think it
is a good idea.

Cheers,
Magnus


More information about the LEAPSECS mailing list