On Mon, Jan 15, 2024 at 6:32 PM Miroslav Lichvar <[email protected]> wrote:
> > > 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
