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

[Poul-Henning Kamp]

In message <60007541-EEB9-4802-9288-9D5AF7BA0705 at ucolick.org>, Steve Allen writ
es:

>On 2010 Dec 19, at 08:07, Poul-Henning Kamp wrote:

>> Right, and you are advocating changing the POSIX standard, so ?

>

>The POSIX standard is broken, admittedly broken, by insisting that

>it conforms to something whose properties it cares not to implement.


I will agree that having multiple mutually conflicting standards is
a bad thing, but I not in any way convinced that POSIX isn't a big
improvement over ITU's current definition of UTC.


>Of the code that cares to match with civil time of day, much assumes

that the same time next day is achieved by adding 86400 seconds to

>a time_t.  Such code already fails by an hour when used across two

>day boundaries every year.


No, because what you are adding 86400 seconds to is a time_t, and
then after the addition you convert to local representation, so
this actually works precisely as it should: 86400s is 24 hours,
no matter what your timezone is.

The trouble in this particular aspect is software like Windows which
stores timestamps relative to local time, without also recording
nearby what local time actually is.


>Change the name of the broadcast time scale from UTC to TI (as

>recommended at the 2003 Torino ITU-R colloquium), omit the leap

>seconds from the broadcasts, and put them into zoneinfo.


Are you seriously suggesting that DCF77 and WWVB should not
transmit the time people expect to see on their clocks ?

Do you have _any_ idea how many alarm clocks in europe are sync'ed
to DCF77 ?

Whatever civil timekeeping is built on top of, these transmitters
will have to transmit.

If civil timekeeping is built on top of UTC, then they will transmit
UTC.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.