Followup to: <[email protected]>
By author: "Brandon S. Allbery KF8NH" <[email protected]>
In newsgroup: linux.dev.kernel
>
> In message <[email protected]>, Chris Wedgwood writes:
> +-----
> | On Wed, Sep 09, 1998 at 12:59:47AM +0000, H. Peter Anvin wrote:
> | > The way xntp deals with leap seconds is it lets the epoch float...
> | > i.e. it holds time_t to the same value for two seconds.
> | Cool... so 1970 becomes even longer ago that I would have assumed
> | then?
> +--->8
>
> That's the only semi-reasonable (I stress *semi-*) interpretation one can
> give to the current standard. The other possibilities are worse.
>
Right. I think the right solution is one I suggested on c.o.l.d.s
recently:
- time_t being a 64-bit signed integer linked to UTC
- struct timespec (and struct timeval, presumably) having an extra
field added:
64-bit seconds field (same as time_t) linked to UTC
32-bit nanosecond field (microsecond for timeval) linked to TAI
32-bit integral TAI-UTC difference
That way any moment in time will be uniquely derivable at least, at a
positive leap second, you will see the progression (where T means a
time_t value divisible by 86400):
tv_sec tv_delta UTC
T-3 N 23:59:57
T-2 N 23:59:58
T-1 N 23:59:59
T-1 N+1 23:59:60
T N+1 00:00:00
T+1 N+1 00:00:01
T+2 N+1 00:00:02
... and for a negative leap second ...
tv_sec tv_delta
T-3 N 23:59:57
T-2 N 23:59:58
T N-1 00:00:00
T+1 N-1 00:00:01
T+2 N-1 00:00:02
We may want to have a testable bit that we're "in" a leap second for
the 23:59:60 case...
-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bah?'? -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Mis?rables
From: [email protected] (H. Peter Anvin)
Date: 10 Sep 1998 01:37:05 GMT
Right. I think the right solution is one I suggested on c.o.l.d.s
recently:
- time_t being a 64-bit signed integer linked to UTC
- struct timespec (and struct timeval, presumably) having an extra
field added:
64-bit seconds field (same as time_t) linked to UTC
32-bit nanosecond field (microsecond for timeval) linked to TAI
32-bit integral TAI-UTC difference
This works, although it would require making a glibc interface change.
But if the ELF symbol versioning works out, perhaps this won't be as big
of an issue.
However, in order to in sync with POSIX.1's definition of how time_t relates to
UTC time, I'd suggest that we make the progression go as follows:
... making the progress go as follows:
tv_sec tv_delta UTC
T-1 N 23:59:59
T N 23:59:60
T N+1 00:00:00
T+1 N+1 00:00:01
(that is, repeat tv_sec == T instead of tv_sec == T-1).
- Ted