the ``need'' for POSIX times

[Paul Eggert]

   Date: Fri, 09 Oct 1998 23:13:35 +0100
   From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>

   Paul Eggert wrote on 1998-10-09 19:16 UTC:
   > struct xtime's TIME_UTC is not really UTC, as
   > TIME_UTC clocks have special values during an inserted leap second,
   > whereas UTC clocks simply go back 1 second.

   ... There is absolutely no conceptual difference between "real UTC"
   and TIME_UTC, since there exists an obvious bijective deterministic
   mapping between both.

No, because "real UTC" is ambiguous during inserted leap seconds.

By "real UTC" I mean the sort of UTC described by Fig. 2 of Terry
Quinn, The BIPM and the Accurate Measure of Time, Proc IEEE 79, 7
(1991-07), 894-905.  This is the UTC that is denoted in the expression
`UTC-TAI', which is commonly used to denote how many leap seconds have
been inserted.

Since 1972, the graph of UTC-TAI versus time has been a staircase
function that looks like this:

   --+
     +----+
	  +---------+
		    +---....

where each decrease corresponds to an inserted leap second.  This
graph makes sense only if UTC clocks are adjusted backwards by one
second during a leap, as I described above.  That is, the `:60'
notation is used to disambiguate leap-second timestamps, but it's not
part of "real UTC".

   Struct xtime is just a simple fully static encoding of the full
   YYYY-MM-DD HH:MM:SS display as found on any official UTC clock.

Let's call this display "display UTC", as opposed to the "real UTC"
mentioned above.  Then clearly the TIME_UTC struct xtime encodes
"display UTC", not "real UTC".

Another way to say it is that struct xtime is a broken-down
representation of UTC, one that contains a special encoding to
disambiguate UTC timestamps within leap seconds.  struct xtime is not
as broken-down as struct tm is, but it _is_ broken-down to some
extent.  And its conceptual problems stem from this fact.

I've heard that, in some C implementations, time_t encodes a
broken-down value, so that localtime simply picks the bits out of the
encoded representation and stuffs them into the struct tm.  This
conforms to C89, but it means time_t is quite inconvenient to deal
with directly.  struct xtime has many of the problems that these C
implementations have (albeit in a more limited way).  I'd prefer an
internal representation that didn't have these problems, if one is
possible.

   There exists no eternally valid static algorithm for this
   conversion in your modified TAI, because the timestamp versus
   displayed time relationship changes each time you update a leap
   second table.

True, but any application requiring such an algorithm should not use
TIME_TAI; it should use TIME_UTC.

   You enter into this electronic commerce system a command to rejects
   all contracts that expire after 2000-01-01 00:00:00,

Such an application should not use TIME_TAI for future timestamps,
obviously.  But, for the purpose of this discussion, let's assume that
the programmer made a bad mistake and wrote code that attempts to
convert every timestamp to TIME_TAI internally, even future
timestamps.

   It converts the 2000-01-01 00:00:00 cut-off date into an integer
   timestamp T based on the assumption that there will not be a
   further leap second until then as the current table
   suggests.

No, the implementation will report an error when the application
attempts to make the conversion, since leap seconds aren't known
that far in advance.  That will preclude the later problems
mentioned in your scenario.

This issue is independent of whether the API uses struct xtime or an
integer clock.

   there are numerous
   applications, where we care much less about the real number of seconds
   until some date than we care about what exactly the precise official UTC
   notation for this date

Yes, and such apps should use TIME_UTC.

   My TIME_UTC (and also POSIX) provides this reliable relationship between
   the easy to process integer struct value and the full broken-down time.

My proposal won't change this.  (POSIX.1 is a special case of my proposal.)

   Your modified TAI does not provide this reliable relationship!

Nor does the unmodified TIME_TAI.  (Sorry, I don't see why these points
are relevant.)

   Just think about legal investigations in the
   context of some fraud, where timestamps in digitally signed documents
   were encoded using your modified TAI encoding.

I wouldn't recommend that people use such timestamps for that purpose,
any more than I would recommend that they use TIME_MONOTONIC.  The
modified TIME_TAI clocks have an implementation-defined epoch, among
other things.  The code wouldn't even get off the ground; it'd be a
silly thing to try.

   I consider [the struct xtime proposal] to be ready for standardization.

I can't agree.  It's not implemented yet.  We don't have any
real-world experience with it.  Even assuming we're willing to live
with its conceptual problems, a lot of work is needed before it's
ready for standardization.  And I'd prefer a spec that had fewer
conceptual problems, before implementation begins.