> the actual system time). But the offset will be wrong by a small number of
> seconds if the system clock is so far in the past that leap seconds other
> than the latest one intervened: I don't think that matters.
That will cause an error in the initial step of the clock and it will
take longer to stabilize.
In computing the initial step, how does chrony handle leap seconds?
There are two ways of computing offsets:
- subtracting the TAI times (so that it is really the number of seconds that elapse between the system time and the true time)
- subtracting the POSIX times (so leap seconds are ignored)
When the offset is small, I am assuming the first way is right (otherwise you would get discontinuities). But if the system offset is a long time in the past (so that chrony is doing a step), does chrony expect the first or the second? The first would require chrony to have knowledge of all past leap seconds.
Or am I misunderstanding something here?
The sample time in the SOCK needs to be in the system time (UTC),
otherwise it will be rejected as invalid.
Right: I'm doing that.
> I compute the leap flags based on the true time: if the true time occurs on
> a day that ends with a leap second, then I set the leap flags. Or should I
> be setting them if the true time is some number of hours before the end of
> the day that ends with a leap second?
The leap should be set until the leap happens, starting up to 24 hours
before.
What does "until the leap happens" mean exactly? Does that mean that adding the offset to the system time gives a time that is < 24:00:00 on the day of the leap second (i.e. the leap second is over)? Or is it until the leap second starts?
James