On Mon, 13 Feb 2023 at 10:32, Miroslav Lichvar <mlich...@redhat.com> wrote:
> On Sat, Feb 11, 2023 at 07:51:27AM -0800, Richard Cochran wrote:
> > On Wed, Feb 01, 2023 at 04:52:15PM +0100, Miroslav Lichvar wrote:
> >
> > > > + if (next) {
> > > > + atop.jumpSeconds = next->local_tai_offset -
> tz->local_tai_offset;
> > > > + atop.timeOfNextJump.seconds_lsb = next->timestamp;
> > > > + }
> > >
> > > Is this intentionally not setting the _msb field, ignoring distant
> future?
> >
> > Yes, it is intentional. The LSB is 32 bits of seconds, so the range is
> >
> > (/ (/ (/ 4294967295 3600) 24) 365) = 136 years
> >
> > It is hard for me to understand why a time zone should change more
> > that one year in the future from a given date?
>
> Isn't timeOfNextJump an absolute time, i.e. will it not overflow 136
> years after the epoch?
>
>From IEEE 1558-2019
"16.3.3.7 timeOfNextJump (UInteger48)
The value of timeOfNextJump shall be the value of the seconds portion of
the PTP Instance Time of the transmitting PTP Instance at the time that the
next discontinuity will occur.
The discontinuity occurs at the start of the second indicated by the value
of timeOfNextJump.
NOTE—If the alternate timescale implements a leap second correction
(e.g., if the alternate timescale is a local timescale at the time of a
leap second,
or if the option of this subclause is being used to compute UTC time at
the time of a leap second),
timeOfNextJump is the time when <dLS> = TAI – UTC changes.
This time is specified by the IERS (see 7.2.4 and IERS Bulletin C).
..."
I agree with Miroslav.
POSIX also address the issue regarding the 'time_t' type:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html
"Implementations in which *time_t* is a 32-bit signed integer (many
historical implementations) fail in the year 2038.
POSIX.1-2017 does not address this problem.
However, the use of the *time_t* type is mandated in order to ease the
eventual fix."
"In a future version of this volume of POSIX.1-2017, *time_t* is likely to
be required to be capable of representing times far in the future.
Whether this will be mandated as a 64-bit type or a requirement that a
specific date in the future be representable (for example, 10000 AD) is not
yet determined.
Systems purchased after the approval of this volume of POSIX.1-2017 should
be evaluated to determine whether their lifetime will extend past 2038."
Seems that instead of 'BUG 2000', we will have 'Bug 2038' :-)
Erez
> --
> Miroslav Lichvar
>
>
>
> _______________________________________________
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
