On Thu, Jan 19, 2006 at 12:59:42PM +0100, Poul-Henning Kamp wrote:
> I would far rather we tried to define a time API for
> POSIX to adopt that makes sense.
>
> By make sense I mean:
>
> o conforms to relevant international standards
> ie: recognizes the defininition of leap seconds since
> for all purposes and intents we're probably stuck with
> the blasted things for another 20 years.
>
> o is workable from a computer architecture point of view
> no more pseudo-decimal timeval/timespec idiocy.
>
> o Caters to the needs of relevant user communities.
Now you're talking sense, Poul! Thanks for your proposal.
> Here's a strawman:
>
> Use a 128 bit signed integer.
>
> Assign the top 120 bits as one integer field with
> resolution of 1/2^56 seconds.
>
> Assign the bottom 8 bits to an enum containing the
> timescale in question.
>
> Assign different timescales very different
> numeric epochs:
> TAI: 1972-01-01 00:00:00 UTC
For TAI I'd suggest 1958-01-01, when TAI and UT were set nearly together.
(I've seen more specific references that TAI was set according to both
UT2 and UT1 - but they weren't the same then. Perhaps within known
error at the time?)
> UTC: MJD's epoch.
That would be midnight in Greenwich of 1858-11-17. I don't see the
connection, and picking a time for which we don't know UT1 pretty
accurately and authoritatively will cause all kinds of arguments.
I'd pick 1972-01-01, after the rubber-second era, and so that
there is an integer number of seconds difference, as usual.
> UT1: Flamsteads birthday ?
Cute. 1646-08-19
> NTP: defined in RFC1305
== 1900-01-01
> Define functions to convert from one timescale
> to another and define ERANGE as a return value when
> outside the functions ability to do so (ie: future
> dates on UTC).
>
> Define a compact ascii (no i18n!) representation for machine
> readable use. (Ie: XML, protocols etc).
>
> Very clearly spell out that any timezone adjustments
> must be carried out-of-band to this field.
>
> Assign the UTC timescale a identifier of zero.
>
> Advantages:
>
> Sufficient resolution to represent any likely physical
> measurement or realizable frequency for the forseeable
> future (13.8e-18 seconds resolution).
>
> Extracting the whole second part can be done by accessing
> only the top 64 bits (which are enough to contain all
> of history and then some).
>
> Conversion to/from NTP timestamps is trivial.
>
> Conversion to time_t is a matter of addition and extraction
> of the relevant 32 bits.
>
> The binary format makes for fast and efficient arithmetic.
>
> By assigning the UTC timescale an identifier of zero,
> the majority of implementations can disrecard the
> multiple timescale aspect in total.
>
> Small platform implementations can use a smaller width,
> for instance 64 bits split 48/16 and easily transform
> to standard format by zero extension.
That would work for 9 million years or so.
> High quality implementations will check the bottom 8 bits
> for identity and fail operations that mix but don't match
> timescales.
>
> Different epochs will make it painfully obvious when people
> mix but don't match timescales in low quality implementations.
Now we just need a name for the proposal....
Neal McBurnett
http://bcn.boulder.co.us/~neal/
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk_at_FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
Received on Thu Jan 19 2006 - 08:55:43 PST