tz package

[Bradley White]

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

Yes, I understand.  Perhaps I should explain myself a little more
clearly though.

My "seconds since the Epoch" *does* explicitly exclude leap seconds in
its calculation - it just keeps ticking, second to second, no matter
what.  If I set my clock to 11:32 local time, then my "seconds since
the Epoch" is exactly right.  However, if you set your clock at the
same time, then your "seconds since the Epoch" will be 14 less than
mine, and 14 less than the actual number of seconds since the Epoch.
You have included leap seconds in your calculation by ignoring them!
Leap seconds are a reality.  Hence, excluding them requires accounting
for them.

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

I agree, all systems should have the same time_t value during the same
second.  Furthermore all systems should have the successor of that value
in the next second.  If one system continues unchanged over a leapsecond
while you decrement your time_t, *then* they will have different time_t's.

>                    These systems could convert the same time_t value
> into a different string.

This is immaterial.  Different systems already convert the same time_t
into different strings depending upon which timezone they are in, whether
they have daylight savings during different parts of the year, etc etc.
In fact, the adotime leapsecond code is *only* concerned with time_t <=>
struct tm decoding and encoding, and hence immaterial.

The issue is that leap seconds should not change the constant and
consistent ticking of "seconds since the epoch", as your reading of the
standard implies.

>                           Make can get messed up, transaction
> time stamps can be wrong, etc... 

No.  If each system just keeps ticking then everything will be consistent
(and "correct").

> Is patch level 1 your current patch?

I assume you received ado's reply.  He is the source source.

Anyway chongo, you are undoubtedly much more familiar with the standards
than I, so there may be other things that are swaying your opinion.  All
I am saying is that there can be (many) different interpretations of the
same text.  In this case I think that the above quote implies behaviour
along the lines of adotime leapseconds.

brad