[LEAPSECS] POSIX and C (Was: Re: ISO Influence)

[Steve Allen]

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