On Sun, Mar 4, 2012 at 16:27, unruh <[email protected]> wrote: > Thus one could, as Hasler does, aruge that UTC is simply an aberation, > like leap years, and like time zones, from the orderly progression of > the seconds (TAI), and should be handled in exactly the same way as leap > days, daylight saving time, or timezones. Others, apparenly like you, > like the idea that the seconds track the day as well as possible. It is > a matter of preference, not some sort of "natural order".
I have no problem with people having a preference for TAI (and its rare days of length 86401 seconds) over UTC (with leap seconds and consistent 86400 second days). I have a severe problem with the concept that the name UTC should be redefined to mean TAI, as an underhanded way to convert lots of other standards like POSIX to TAI by fiat. The resulting confusion of "old UTC" vs "new UTC" would create many more problems than it solves. Yes, it's sometimes annoying that you have to account for leap seconds to use historical UTC times for accurate interval calculations. Forcing a world of software that expects 86400 seconds in every day to be updated to redefined UTC which is really TAI doesn't really solve anything -- it just moves the pain from one set of issues to another. If you want to use TAI, knock yourself out, but if you do that by redefining time_t to represent the TAI timescale, what have you gained? An incompatible, indiscernable source of error where your time_t leaks into interaction with standard time_t. It might have been nice if time() had originally been designed with perfect foresight, that horse has left the barn, and those who think they can put it back in through a redefinition trick are delusional. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
