Fixing POSIX time

From: Neal McBurnett <>
Date: Thu, 19 Jan 2006 09:54:51 -0700

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

> --
> 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

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT