On Jan 10, 2014, at 8:35 PM, Skip Newhall wrote: > '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.
Prescribe is the word I intended. POSIX mandates, requires, prescribes that time is UTC. > -----Original Message----- > From: leapsecs-boun...@leapsecond.com > [mailto:leapsecs-boun...@leapsecond.com] On Behalf Of Magnus Danielson > Sent: Friday, January 10, 2014 6:24 PM > To: leapsecs@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". I missed that part... > 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. Yes, you have to break one of the conditions that are in conflict.... > 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. True. But also most of the time computations are done without knowledge of leap seconds. > * 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. How do you know the applications that are about this? The vast majority of applications don't care about UTC. If the library routines implement it without hassle, then they are happy. If not, they are happy too. The problems come from the ambiguity between using time as an interval and using time as an absolute time. The difference between 12:34:45 today, and 24 hours from now. Leap seconds make computing tomorrow at this time a little more complicated. Interfaces could be made to this, but it isn't currently deployed... > * 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. The conversion from TAI to UTC is not possible without ambiguity (although there's no unique mapping for the leap second, and many conventions for the non-unique mapping). It is also not possible to convert Jan 10, 2015 12:34:56 UTC to a TAI time, nor could I convert the same time to a UTC time because we don't yet know what time label that second will have. And we won't know until sometime this summer. So looking back you can make the conversion (assuming you have leap second table). It gets complicated from 1958 to 1972 when leap seconds didn't exists, but phase and frequency offsets were introduced into UTC (or the thing that was becoming UTC). time_t is in integral seconds (by tradition, float is possible but not done typically), and may or may not be defined prior to 1970 (it is an arithmetic type, which may or may not be signed). > * 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. If you always use TAI, it can be converted to UTC, but not using a simple counter since the encoding at the leap second wouldn't exist. And since it doesn't exist, strptime couldn't, for example, render 23:59:50. It would have to be fed TAI times to work properly. > * For most usage, UTC or local time is a presentation issue. Yes. There are many clever ways to cope. The right time zones come close. > 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. Yes. That ensures that you have a more meaningful range of times you can convert between UTC and TAI. It does possibly break DUT1 limit of 1s. We have that issue today, but at a much lower probability (after all the earth is only predictable within certain limits). So a new interface may be possible... Warner > > Cheers, > Magnus > _______________________________________________ > LEAPSECS mailing list > LEAPSECS@leapsecond.com > http://six.pairlist.net/mailman/listinfo/leapsecs > _______________________________________________ > LEAPSECS mailing list > LEAPSECS@leapsecond.com > http://six.pairlist.net/mailman/listinfo/leapsecs _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
