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@cantrip.org