In message: <[EMAIL PROTECTED]> Tony Finch <[EMAIL PROTECTED]> writes: : > The nature of the uncertainty is very different. The uncertainty of : > future UTC can be managed, but for timezones the only sane path is to : > eschew their use entirely. : : That isn't possible for applications like appointment books and job : schedulers. As Warner suggests, you need to calculate future times : provisionally, and in a way that insulates you from discontinuities. : For example, "same time tomorrow" instead of "in 86400 seconds".
And 'same time tomorrow' might not exist depending on the timescale that's used. Cron runs into this problem (and has solved it) because it runs in localtime which has hours repeated or omitted twice a year. Leap seconds are handled in an ad-hoc way as well, typically the last second of the day is repeated for a positive leap-second so cron jobs on fast machines that run at midnight UTC don't run twice. There is a more subtle point that I should mention explicitly. The folks that say "do everything internally as TAI time" tend to forget that to do that one must restrict one's self in a number of important ways. Because certain things are almost always in UTC time (IRIG timecode, measurment of atomic clocks for BIPM UTC calculations, etc), one must take care to know that when you convert a time into TAI from UTC that you can then make the inverse computation and arrive back at the same time. One must also know the appropriate TAI-UTC offset for that time. Typically, one doesn't schedule things in these kinds of systems too far in the future, and one's historical data processing is handled offline where perfect historical knowledge of leap is available for dealing with long or abnormal intervals. Of course, needing to know TAI-UTC offsets leads one to interesting situations. What does one do if one has TAI time, but not UTC and a conversion is asked for? Is it right to pause that thread until it is available, or is an exception right? Pausing the thread means that less code has to deal with this ugliness and makes it so the programmer doesn't have to know that time1 - time2 might fail randomly. However, pausing can lead to deadlocks if the thread that acquires this knowledge pauses. Throws in an exception avoids the deadlock case, but makes every single time expression prone to having to deal with exceptions, which can be tedious and time consuming to code every single time. In C++ this can be really bad because operators are often overloaded for time libraries to make the time types look like native. There are a number of sources of phase (rtc clock, UTC time, TAI time, GPS time, NTP servers) and a number of sources of TAI-UTC (internet ftp, GPS almanac, Loran Data Channel, local data file). The arrival of the data from these sources may be asynchronous, and the cached value may be too old to be useful (for spares that have been sitting on the shelf for a few years). The data sources might be unavailable because the device is cold starting, or because the antenna cable is damanged. These different scenarios have different "right" things to do. The data can also expire because that GPS antenna has been damanged for too long and you don't know the next leap second is coming... Calculating time intervals for times 6+ months in the future can be the least of one's worries when one tries to code up a library to deal gracefully with these different failure modes. The trivial case where one has perfect knowledge of TAI-UTC and one can keep that knowledge current is very simple in comparison. Dealing with this case is very simple, and is the way most people think about leap seconds. But dealing with the edge cases can be difficult because there are so many, and so many that people forget to test or conceive of until the call from the field comes in with a failure... Warner