Friday, February 05, 2010

on leap seconds and syslog

I was recently asked how syslog handles leap seconds. I thought it would be useful to reproduce my thoughts, initially expressed via private mail, here in the blog.

RFC5424 specifically forbids leap seconds, as during our discussions we found many cases where leap seconds caused grief. I also think the the TAI is considering aborting the use of leap seconds for this reason as well. To the best of my knowledge, GPS also does not use leap seconds. The ultimate reason to abandon UTC leap seconds in syslog was the we failed to identify an operating system that would expose leap seconds to a user process. So a syslogd or any other syslog sender would not even be able to see that one was introduced. From the syslog perspective, a leap second is just like any other second, but time flows "somewhat slower". I guess we are in the same boat as many operating systems with this perspective.

In RFC5424 we didn't explicitly state what time stamp should be written during a leap second - because we thought it could actually never happen (why? explained above!). But I would say that "Leap seconds MUST NOT be used" to me means that it should be expressed as the 59th second of said minute. But even if you bump the minute and use the 0 second, I cannot see how this should be problematic. On a single system, time should still evolve serially. For correlating events form multiple systems, the timestamp alone is insufficient in any case. You cannot closely enough synchronize the different real time clocks. So you need a different meachanism (like Lamport clocks) for this in any case.

2 comments:

Steve Allen said...

Undeniably the situation is confused, but until there is a substantial pronouncement otherwise, current international agreements demand that the time scale called UTC have leap seconds. There are several ways out of this, but no clear progress toward any of them.

Rainer said...

Hi Steve,

I agree that the situation is confused. But we decided to leave out leap seconds for the reason I quoted. Granted, this may not be inline with international agreements, we saw that supporting leap seconds would cause large grief. For example, you usually can not store timestamps with leap seconds into databases - they will reject that format. As I wrote, I think this is a good compromise, especially assuming the OS supports leap seconds by letting time running somewhat slower to accommodate for them (the typical approach).

Rainer

Busy at the moment...

Some might have noticed that I am not as active as usual on the rsyslog project . As this seems to turn out to keep at least for the upcomi...