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