Re: [Ntp] [EXT] Re: NTPv5 draft suggestion to move timescale offset into extension fields.

[David Venhoek <[e-mail]>]

The first example that comes to my mind is system local timescales. If
you start one today, with the current scheme you would be forced to
start it in era 1 or you can never properly communicate its relation
to utc, because the offset is more than 2^31 seconds. Looking long
term, this becomes an issue if you want to start transmitting the
system local timescale before knowing what the current time in utc is,
because you might not be able to know the correct era before knowing
the current utc time, and if they use slightly different definitions
of seconds, the era number needed might even dynamically change if you
start the system local timescale around the middle of the utc era.

Another example is when one is running a physics experiment where
using a different timescale is used to blind the measurement data
during analysis (to avoid bias from knowing the answer you expect). If
you don't choose the starting point for that timescale correctly
(within ~70 years of 1900) you may no longer be able to combine the
timescale with utc in a single ntp exchange (which you may want to do
in the boxes where you monitor how your experiment timescale
correlates to tai).

On Mon, Jan 16, 2023 at 10:58 AM Miroslav Lichvar <[e-mail]> wrote:
>
> On Fri, Jan 13, 2023 at 03:19:30PM +0100, David Venhoek wrote:
> >  I think it would be best to also include an
> > explicit era number in that extension field. This would give us
> > maximum flexibility in the future with regards to the zero point of
> > new timescales, instead of having that be forced to within a window of
> > about 70 years (wraparound is every ~140 years, so if two zero points
> > are more than ~70 years apart the "closest" era heuristic no longer
> > works).
>
> I'm still not convinced we need to support different timescales using
> different era numbers.
>
> Can you please provide some examples?
>
> --
> Miroslav Lichvar
>