[LEAPSECS] POSIX and C (Was: Re: ISO Influence)
sla at ucolick.org
Wed Dec 22 12:51:15 EST 2010
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 <sla at ucolick.org> 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
More information about the LEAPSECS