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

[Paul Sheer]

Steve,

Your plan to put leap seconds into the zoneinfo is the
one I intuitively like the most.

But what if a programmer uses gmtime() to convert in one
direction but my_custom_mktime() to convert back??

To explain -->

In terms of how most programs deal with zones, the
only function which cleanly and portably gives the
local timezone is ftime(). This function works on
every Unix system and on Windows.

Once a programmer can get the local GMT offset in minutes, he
is free to code all time calculations himself. For instance
multiplying or dividing by 86400 to convert seconds to and
from ascii "YYYYMMDDHHMMSS+ZZZZ".

Sending either the seconds value or the ascii value over a
network or into a database is also done - sometimes to be picked
up by another OS. At the end of the day the reverse conversion
*must* work.

-paul



> 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.  The authority and wishes of POSIX do

> not constrain the politicians from capriciously messing with the

> civil clocks, we all just have to cope.

> 

> Code which makes use of zoneinfo to verify whether a daylight/summer

> time boundary is being crossed gets the civil time right.  If the

> leap seconds leave the broadcast time scale and go into zoneinfo

> then those programs will continue to get the civil time right.

> The other systems are already wrong and will not get notably more

> wrong if they are following a time scale named TI instead of UTC.

> 

> 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.

> 

> The technology to do this is in place.  I expect that an inventory

> of the systems adversely affected by this will indicate a smaller

> effect than any of the other options. 

>                                                         

> --

> Steve Allen