On Wed 2010-12-22T10:33:41 -0700, Warner Losh hath writ: > This doesn't really change that unless you change > programs to grok the new paradigm. There's a lot of code that assumes: > > time_t t; > t += 86400; > > is the same time tomorrow (or other variations on a fixed-length day), > which POSIX mandates, but which doesn't model UTC around leap seconds.
It happens that I am refactoring just such code at this moment. It is very sloppy code that ignores timezone issues and hopes that nobody will notice if the event happens a little off once is a while. A lot of the reason there is sloppy code is because of the lack of clear direction about the way UTC and POSIX relate to each other. Why bother implementing it "right" when a review of the literature shows that nobody agrees on what "right" is supposed to be? Yes, there is a lot of sloppy code out there. Removing leap seconds from UTC might fix some issues, but it won't fix all the other aspects of bad code. A new name for the broadcast time scale would give a very clear direction that review and revisions are needed. In the mean time even the most rigorously correct code will only be off by a second, and then another second, incrementing over a period of years. I don't see this as much worse than the status quo. -- Steve Allen <[email protected]> WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
