[LEAPSECS] Lets get REAL about time.

[Stephen Colebourne]

On 20 January 2012 11:29, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> With the leap-seconds still unresolved, it is time that we get real about

> time in the computer business.


True. I'm attempting to work out something better in Java at
ThreeTen/JSR-310. Co-ordination may be needed here.


> How anybody could get the demented idea that a mixed-radix format

> for time representaiton could be a smart move is totally beyond me.


Java only has a 64 bit primitive value, so we are effectively forced
into using two numbers.


> How many bits of resolution do we need ?


The Java group decided on "nanoseconds in the age of the universe".
Not that anyone needs to specify a point in the far future/past to the
nanosecond, just that its easier to have a single level of accuracy
for all time. The "age of the universe" was non-contentiuos. The
nanoseconds part was a requirement driven by some database vendors
that store amounts to nanoseconds (accurate or not).

The Java spec currently uses 64 bit seconds and 32 bits for
nanoseconds. Only one person so far has asked for attoseconds, and I
think thats overkill myself.


> We could invent a new data type, "int80_t" or something, but that

> would be a lot of work, so let us just bite the bullet and use one

> we already have:  IEEE binary128 floatingpoint, also known as

> quardruple-precision floating point.


Floating point? What is 0.1 + 0.2? (Not coded in C for donkeys years myself)

There is an IEEE spec for a large decimal number, which would be
preferable. Or a 96/128 bit integer.


> Next comes the question what we do about leap-seconds, and there

> is only one answer that works in practice:  We make them a

> representation issue.

> Our new timecale should run on the TAI timescale which does not

> have leap-seconds or any other artifacts, and library functions can

> convert that to UTC time, civil time etc, using a leap-second table

> which can be updated as and when leap-seconds gets announced.


When designing the Java API, I concluded that it was a user choice as
to the time-scale they wanted. There are three choices:
- TAI
- UTC
- "86400sec" (aligned to UTC days, but always with 86400 "seconds" -
ie not necessarily SI seconds)

Its a user choice because defining a time in the future will not be
accurate if using TAI seconds alone. The code defines TAI and
"86400sec" as epoch-nanoseconds, but UTC is defined as
modified-julian-days+nano-of-day (up to 86401 seconds). My take is
that the "86400sec" form is the one most users want, even though it is
inaccurate (with rubber seconds via UTC-SLS).

So, I don't think that running solely on TAI works in terms of what
users want to do. So, it depend on whether you want your API to be
user-facing, or as a basis for another level that adds the "86400sec"
scale.


> A IEEE binary128 number containing time on the TAI timescale

> counted in SI seconds since 2012-01-20 00:00:00 UTC.  The exact

> epoch is not imporant, but it is a good idea to make it different

> from all other currently used epochs, to make programmer mistakes

> clearly visible.


+1 on the epoch being different


> ]] int tai_time(realtime_t *timestamp, double *error);

> ]] int run_time(realtime_t *timestamp);


Both look reasonable at first glance, but I'm not a user of the
equivalent C APIs today, so my comments there are limited.


> In all other cases, this timescale represents elapsed time in SI

> seconds, and two successive calls to this function will always

> return two timestamps in increasing order.


A guarantee of always increasing would be useful.


> We treat UTC as another case of the larger class of civil timezones.

> Converts the timestamp to "broken down time" in the specificed

> timezone, applying leap-second corrections, daylight savings time etc

> as directed by the "tz" paramter.


I'm sceptical of the time-zone approach. I find a user demand to
record instants in time, but believe that they are days of 86400
"seconds". Does this API return a "broken down time" (fields) with a
second-of-hour of 60? Again, while that is accurate according to UTC,
I don't believe its what users *want* (it forces every query of
seconds to have to handle leapsecs, which is undesirable for API
usability).

Its a tough problem. Form the looks of it, your API would provide good
info, but you need to explain how a user would set timestamps in the
future beyond the known leapsec horizon. I don't think this API can.

Stephen