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
> [EMAIL PROTECTED]         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.

Reply via email to