My Response to PC-US0010 (Eggert)

[Paul Eggert]

   Date: Fri, 19 Jun 1998 17:23:06 +0100
   From: "Clive D.W. Feather" <clive at on-the-train.demon.co.uk>

   What I did was wrote half the process - convert unnormalized time
   to a number of TAI seconds since some epoch.  Rather than writing
   the other half and risking inconsistencies, it seemed better to
   simply express it as requiring the normalized time to produce the
   same result.

The draft C9x spec in effect allows the implementation to consult an
oracle to determine part of mkxtime's output, which means the draft
actually specifies a relation between mkxtime's input and output.
Since it's a relation, and not a function, there's not much point to
writing the inverse.

It's OK to require that the input members of the normalized time
should remain unchanged when passed again to mktime/mkxtime; but it's
not OK to also require that mktime return the same time_t value, or
that non-input struct members (e.g. members not required by the
standard, or tm_ext if that kludge is preserved) preserve their
values.

   You've made me spot one gap in my logic. If you set tm_leapsecs to 0
   before normalizing, the time is effectively TAI, while if you set it to
   _NO_LEAP_SECONDS it is effectively UTC. The output, however, is always
   UTC (unless there is no leap second database, in which case tm_leapsecs
   is set to _NO_LEAP_SECONDS). There's no trivial way to convert it to
   TAI, unless you know of an algorithm. Do we need a _USE_TAI value as
   well (indicating that the result should be TAI) ?

I don't think the current draft's primitives are suited for conversion
between UTC and TAI.  If it were, then there would have to be an easy
way to generate a broken-down TAI time from a time_t value.  If it's
important to support things like this, the primitives need to be
rethought.  But I suspect that the vast majority of users don't care
about TAI, and that this sort of feature doesn't need to be in the
standard.

I believe that the <time.h> primitives need rethinking anyway.  If
we're going to reform mktime, for example, we should separate the
original broken-down time from the broken-down time to be added, since
that will remove some gotchas with the current approach.  E.g. one
month after Aug 31 ought to be Sep 30; but mktime yields Oct 1 because
it can't distinguish ``add one month to Aug 31'' from ``add one day to
Sep 30''.  (This problem also resurfaces with leap seconds.)

But more important, implementation experience, both on the part of
implementers and users, is necessary before the standard is changed.
It's unwise to add more <time.h> primitives without significant,
public real-world experience.