Leap Seconds

So this has come up because I’m writing a NTP client.

Does the .netmf support Leap Seconds?

[quote]Leap Indicator (2 bits)
This field indicates whether the last minute of the current day is to have a leap second applied. The field values follow:
0: No leap second adjustment
1: Last minute of the day has 61 seconds
2: Last minute of the day has 59 seconds
3: Clock is unsynchronized[/quote]

When is the last time we went backwards (59 seconds for last minute instead of 60 or 61?)

(just curious)

I suppose I could google it. Hmm

@ mtylerjr - “However, negative leap seconds have never been needed since the UTC standard was established, and are highly unlikely to ever be.”

Most recent leap second - June 30, 2015 at 23:59:60 UTC.

1 Like

So because of leap seconds. I have to set the time on my robot everyday. I was planning on weekly but now it’s daily. No problem, so long as it’s connected to the internet.

I was planning to use a GPS module to get the time from. but it costs money.

Because of accuracy of 32.768khz crystals, you’d have to set the time regularly. Just not worth thinking about it any other way. OR… you could just ignore the fact that it’s time is 10 secs different to “real” time. It’s not like it actually needs time sync, does it ?

@ Brett - Actually, I need accurate time on the robot for logs, and encryption purposes.

I call bull. Sorry.

If you need accurate time for encryption, then connectivity isn’t a problem.

If you need accurate time for logs, then it’s all relative, and accuracy is not needed to the second. If you’re trying to correlate logs between two sources, then more important than absolute time is accuracy between the sources. How often does the other source actually change it’s time ? And really, do you have that many log entries that you won’t be able to sync them ?

@ Brett - Well I don’t need to be accurate to the millisecond, and yes there would be more than 2 log sources that need to correlate. All the robots upload their logs to the central servers periodically. As a software guy, I know the importance of having accurate time on a class 1 computing device.

And how often are you going to send logs? You can establish time drift at that point, right ?

Weekly log uploads. I intend to keep a RTC running with a coin cell so that the time keeps even if off.

With only weekly log collation, you are unlikely to be interested in “real time” event correlation, so I would expect that the RTC on it’s own will probably be good enough (but will still drift differently on each bot based on the accuracy of the crystal and circuit, which are not that accurate ).

Accuracy of the timestamps on a set of information sources is directly related to the time between an event and when you can act on that event information. If there’s a gap of a week compared to a gap of a minute, it’s clearly more important to have accuracy and synchronicity in timestamps in the second scenario. With a gap of a week, you may well only be looking for events in the same minute, or 5 minutes… It won’t really help you to know that these things happened a second apart on Bot A, then B, then C, a week after it happened, will it ?

If something happens on more than one machine at a specific time, at a specific customer, then I’ll be able to tell that customer hey it’s something in the environment, not the machines themselves. “Look all 3 machines started recording errors at exactly 8:25:15 AM.” But if one happened at 8:25 and another happened at 8:30 and another at 8:10, then I’ll have to look much deeper to figure out what went wrong. The accurate time stamp would help me to quickly determine if the problem is internal or environmental.