[LEAPSECS] presentations from AAS Future of Time sessions
Skip Newhall
x at sn.to
Fri Jan 10 22:35:01 EST 2014
'Proscribe' and 'prescribe' are distinct words:
'Proscribe' means to forbid, disallow, or prohibit. "School rules proscribe the use of pencils on exams."
'Prescribe' means to lay out specifications or rules about something. "In the manner prescribed by law."
I don't know the context of the sentence the Magnus refers to.
-----Original Message-----
From: leapsecs-bounces at leapsecond.com [mailto:leapsecs-bounces at leapsecond.com] On Behalf Of Magnus Danielson
Sent: Friday, January 10, 2014 6:24 PM
To: leapsecs at leapsecond.com
Subject: Re: [LEAPSECS] presentations from AAS Future of Time sessions
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
<mailto:LEAPSECS at leapsecond.com> LEAPSECS at leapsecond.com
<http://six.pairlist.net/mailman/listinfo/leapsecs> http://six.pairlist.net/mailman/listinfo/leapsecs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140110/752ddafe/attachment.htm>
More information about the LEAPSECS
mailing list