A leap second will be added at the end of the year 2008. That is after 23:59:59, a positive leap second at 23:59:60 would be counted, before the clock indicates 00:00:00 of the first day of 2009. The addition of a leap second may mesh up with the time synchronization of your software and your application may end up functioning in an unpredictable way.There are two ways of measuring time that are considered accurate. Astronomers work with Universal Time defined by measuring distant astronomical objects outside our galaxy. The rest of the world uses average time of a number of atomic clocks around the world to measure the time. However these two time systems do not stay completely in synchrony, but there is a somewhat upredictable drift between the two time systems. Therefore modern computer systems use Coordinated Universal Time (UTC) measured with atomic clocks and then synchronized occasionally with the astronomically measured Universal Time so that the time difference between the time systems will stay within one second maximum. The synchronization occurs by adding a leap second at the end of a UTC day based on measured time difference.

There is no way a computer application can predict the occurrence of leap seconds. The addition of leap seconds are based on measured drift between the astronomical and the atomic clock times and the the drift can only be experimentally measured. Furthermore some committees decide the actual occurrence of the leap seconds based on the measured drift. Network time servers provide the accurate UTC time, client computers synchronizing their internal clock with the UTC time. Time servers are also capable of announcing the leap seconds to their clients. Different time server clients and operating systems then deal with the leap seconds differently.

So how does LabVIEW deal with the occurrence of a leap second? There are two different functions we need to consider. First is how does Tick Count (ms) and other millisecond resolution LabVIEW timer functions deal with the leap second. Will there be discontinuity in the tick count value? Will this discontinuity be different on different platforms? The tick count is most propably returned by the operating system so the answer will be OS dependent. The tick count on real time and FPGA platforms is hardware dependent and may differ that of the OS returned tick counts. I don’t know the answer. Second issue is how does the leap seconds affect time stamp related functions. According to NI Developer Zone article on LabVIEW timestamp, the leap seconds are ignored. What does it mean? Honestly, I don’t know the answer to either of these questions. However this article on network time protocol may give a hint. For more detailed introduction to the problematic of leap seconds, see this blog article at meta/LPAR.

If you have extra energy, leave your  network time synchronized LabVIEW environment to measure tick count and OS time stamp over the UTC year change to see what really occurs. Note that UTC year change occurs at GMT time zone. Reports are most welcome.