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
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
