[LEAPSECS] presentations from AAS Future of Time sessions

[Magnus Danielson]

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