
[apologies if this has been seen before.] Part of the problem with struct tm/time_t is that it works ok for inode times but not for other equally-important uses. The problem with the mktime model is that conversions between civil time and timestamps can result in 2, 1, or <1 valid conversions, and neither the user (before the conversion) nor the library is equipped to favor one result over another, or deal properly with nonexistent times. mktime offers no interface for the algorithm to report what it finds, so it must falsify its results. I hope that any interface offered to improve on mktime will expose the information needed to write reliable code. If it is also "nice" for the common ranges where there actually is a one-to-one mapping, that's a bonus, but correctness should come first. Nathan Myers ncm@cantrip.org http://www.cantrip.org/

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. 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. ---Dan 1000 recipients, 28.8 modem, 10 seconds. http://pobox.com/~djb/qmail/mini.html

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
participants (2)
-
D. J. Bernstein
-
Nathan Myers