In message <[email protected]>, 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 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
