synthesis ?

Paul Eggert eggert at
Wed Oct 14 21:37:40 UTC 1998

   Date: Tue, 13 Oct 1998 17:47:19 +0200
   From: Antoine Leca <Antoine.Leca at>

   we can classify all the possible implementations in the following order:

   1st, those implementations that know both UTC and TAI "perfectly"....

   2nd, those implementations where the clock is UTC based and that
      have some knowledge about leap seconds, but where the famous table
      is not known to be correct.

(1) and (2) actually form a sort of continuum, not a dichotomy, since
no implementation can know UTC-TAI "perfectly" for all future
timestamps.  In other words, all implementations (even libtai, or
Olson in "right" mode) operate with incomplete leap second tables;
it's just that some tables are more incomplete than others.

A simple way to allow both (1) and (2) is to have an API that makes
the leap second table accessible.  Once you do this, you can support
all the implementation continuum between (1) and (2).

   3rd, those implementations that only know about UT [without leap seconds]...

   4th, worse, those ... that ... only know "some form of local time"....

   5th, if it even exists, those that cannot figure what time is it.
      I doubt it really exists, but traditionnaly C handles them.

   My idea is that the API to be proposed should work OK and smoothly
   with all classes, with priority given to the highest class(es) where
   there are choices to make.

That sounds reasonable, and an integer-timestamp API can do this, as
does the struct xtime API.

   The main point is that everything (except the last class!) ends
   up as counts of seconds, and sometimes subseconds; but having
   to manage 2 functions for each functionnality seems too much
   for me; therefore I prefer something along the lines of
   struct taia or struct xtime.

Sorry, you've lost me.  If you want a simple integer timestamp, you
don't need 2 functions for each functionality; it suffices to return a
single count of subseconds.

C9x has 64-bit integers, and 64-bit subsecond timestamps suffice for
the vast majority of applications, so it's reasonable to return a
single integer instead of returning a struct.  Higher-quality
implementations can return even longer timestamps (e.g. 128 bits) if
there is need for this.

More information about the tz mailing list