tz package

[Landon Curt Noll]

 >> I suggest that you put a BIG warning around the use of 'leapseconds'
 >> in time calculations.  For a number of reasons, POSIX (IEEE standard
 >> Unix, soon to be ANSI and ISO standard unix) prohibits the standard
 >> conversion to/from "Seconds since the Epoch" functions from taking
 >> leapseconds into account.
 >
 >I think we came to the conclusion before doing the leapsecond stuff that
 >the wording in POSIX *requires* that standard conversion routines take
 >leapseconds into account.

Just to be sure we have communicated...

POSIX really does state that "seconds since the Epoch" explicitly
excludes leap seconds in the calculation.  Since all current POSIX
time conversion functions and time_t timestamps derive their value from
"seconds since the Epoch", no POSIX function can make use of leapseconds.

This is not to say that a later draft could not add NEW functions that
do take leap seconds into account.  But since P1003.1 is NOW in FINAL
BALLOT, it will be a long time before such a standard function would
show up.

The impact of adding leapseconds as you have done can be more than a
simply 'my clock is 14 seconds slow'.  Networks of systems or multi-os
systems or multi-cpu systems could have a different time_t value for
the current time.  These systems could convert the same time_t value
into a different string.  Make can get messed up, transaction
time stamps can be wrong, etc... 

That is why I suggested that you point a big warning about not
using leapseconds.  No system using them can ever be POSIX
(or SVID since it will conform to POSIX) and no system as shipped
by a major (or minor?) computer builder uses them.

Is patch level 1 your current patch?

chongo <> /\oo/\