new C time interface

Nathan Myers ncm at
Sat Oct 24 02:27:23 UTC 1998

D. J. Bernstein writes:
 > Nathan Myers writes:
 > > The problem with the mktime model is that conversions between civil
 > > time and timestamps can result in 2, 1, or <1 valid conversions,
 > That's true only if you omit the UTC offset.

Yes, but it's a rare wall clock, legal document, train schedule, or 
airline ticket that indicates UTC offset, and when it does it's 
likely to be wrong, especially during the "interesting" times.

 > The basic structure for civil times in libtai is struct caltime, which
 > includes a calendar date, a time of day, and a UTC offset. caltime_tai()
 > converts struct caltime to struct tai.
 > You're asking how to determine the UTC offset when a user types a date
 > and time. With libtai's time-zone support (under development) you'll be
 > able to see all the possible UTC offsets in this time zone, and check
 > for each one whether it's consistent with that date and time.

The problem that normally arises is that someone enters a date/time
and I want UTC/TAI for it.  If it's in spring and they enter 0230, it
might not exist; but there's a good guess (e.g. equiv. to 0330) for
what they probably meant.  In autumn, it is harder: if they enter
0130, did they mean the first time it happened that day or the second?
If they enter 0230, did they mean officially 0230, or did they mean
the second 0130?

The conversion function should reveal all these interpretations 
(including leap-second alternatives) and let the client do what 
disambiguation it can after being fully advised.  Given how confused 
application coders get about time computations, the library should 
leave little room for mistaken assumptions.  Thus, alternative offsets 
based on variant leap-second interpretations should be presented 
separately from more-substantial differences, and be ignorable.

A struct containing up to four TAI values, with associated
interpretation and confidence tags, might suffice for the
result of such a conversion.

Nathan Myers
ncm at

More information about the tz mailing list