What is a Leap Second?
The time when the civil clock was defined by the position of the sun over Greenwich UK is long gone. Instead, atomic clocks (International Atomic Time – TAI) have become the tick-tock in the clock of civilization. However, there is still a need to synchronize the perceived time of day (Universal Time – UT1 or variations thereof) with the official time used in civil life and commerce (Universal Coordinated Time – UTC).
This coordination is the task of the International Earth Rotation and Reference Systems Service (IERS) at the Observatoire de Paris. IERS can name specific dates (at end of June or December, but also end of March or September), to insert or remove single seconds (so called leap seconds) to make sure the predicted difference between UTC and UT1 stays below 0,9s. In January 2015, the IERS announced that the next leap second will be inserted on the night (UTC time zone) between June 30 and July 1st 2015.
High Accuracy Environments
For most situations in global commerce, there is no need for sub-second accuracy and representing the full time continuum. However, there are situations where additional requirements on precision and accuracy exist. This is the case with stock exchange, trading or auction applications, or when specific legal requirements require reference clocks.
Such requirements need systems to handle specialized time-keeping (because the system time cannot deal with leap seconds and the time synchronization by Windows Time Service or NTP might not be precise enough). This can include special time stamping on a hardware level.
Most server systems represent the current time in seconds since a defined start date. The Unix-time (also known as Posix-time) is defined in seconds since January 1st, 1970 0:00Z. Windows file time is defined from January 1st, 1601. In both cases, leap seconds are not taken into account, which means each day is exactly 86400 seconds long (and start at a multiple thereof).
The current time for Java System.currentTimeMillis() is represented in milliseconds since the start of 1970 with the same 86400 seconds days assumption. The integer which represents those milliseconds can be used to store the time (for example in a database column) or it can be converted into a calendar string. This is done with the help of Java Time Zone information .
Java lets the operating system decide how to align the time with the real clock. It depends on the operating environment (Kernel, Configuration, Installed time synchronization), but generally, all commons systems will step the clock back by one second around midnight. This leads to time stamps which are not monotonic (meaning they might have decreasing values), and events happening after the time adjustment will have smaller numbers than the event before (for roughly one second).
There are not usually problems expected to arise from this alignment. However, you need to make sure that custom code or solutions do not require a strict monotonic sequence. If you have such requirements, you might want to pause processing around UTC midnight (or implement additional logic to make the timestamps monotonic). It is generally better not to rely on unsequenced timestamps because the clock can be adjusted even during regular operation or run into issues when the timestamps of different machines differ as may be the case in a distributed installation.
Most Linux/Unix systems (especially with NTP daemons installed) do know about leap seconds and make sure to set the time back 1s exactly before or after midnight.
The Windows time service w32time on the other hand does not schedule the leap second. The next synchronization run (typically in the first hour of the next day) will recognize a time difference and step the clock 1s backward.
Both systems have the problem that Java will see a step back in time (with possible duplicate timestamps and no way to represent the entire UTC time continuum with sub-second precision), unless a rather uncommon configuration or software is used.
Leap Second Linux Kernel Bugs
In the past, there have been some bugs in Linux Kernels which caused the machines to lock-up or consume high CPU after a leap second. Java applications especially, which are highly multi-threaded and use a lot of synchronization primitives of the kernel, have triggered those bugs. The bugs have been fixed, and you should consult your operating system vendor to make sure you use a recent kernel.
According to RedHat RHEL7 is not affected by the old kernel bugs. RHEL6 is affected by the CPU-consumption bug unless you install Linux kernel-2.6.32-358 or newer (Bug#836803 in Errata RHSA2013-0496).
According to SuSE SLES 11 SP1 (fixed in kernel-184.108.40.206-0.7.1) + SP2 (fixed in kernel-3.0.38-0.5.1) are affected.
Java and Leap Seconds (SEEBURGER Software)
The Java system time does not use leap seconds, meaning it is not producing timestamps which represents time outside the normal 0-59s time strings. This is a good thing for compatibility with partners and systems.
It also means that when timestamps are produced around a leap second, they might not monotonically increase. Some functions (for example creating time based UUIDs) are safe to use with those duplicate timestamps (and will not create duplicate IDs).
In SEEBURGER software, we take care of planned and unplanned time steps by using a special clock which is (normally) monotonic and is not affected by time adjustments (System.nanoTime()). This can be used for measuring elapsed time and schedule short wait times.
Time Representation and Time Data Processing
In addition to operating system time, applications also produce and parse time stamps when communicating.
Java will not produce timestamps with leap seconds (i.e. 23:59:60+0000). This is the safest way of handling time. Even when the protocol or data format allows for this representation, one cannot be sure if it actually gets understood by other systems or applications that connect with it.
Some data formats and protocols do not allow leap seconds or do not clearly specify if leap seconds are allowed. For example the dateTime type of XML Schema 1.1 does explicitly forbid the leap second “60”. In commercial EDI messages seconds are used rarely anyway. But if they are used typical implementation guidelines specify 00-59 as allowed values.
For EDIFACT, this especially is based on the DTM segment. The Date:-header in Internet Mail does include a :60 second and therefore supports leap seconds. FTP will transmit timestamps of files; they are typically in Posix-time or Windows FileTime, and therefore never show a leap second.
When parsing time-date string with Java (XPath, SimpleDateFormat, …) a :60 second can either be accepted and rounded down to 59 or it can produce a parsing error. It depends on the component used to determine which configuration should be chosen. Typically, lenient parsing is used whenever the timestamps have only informational character.
The Leap-Second happens at the same moment all over the world, which means they are added at different hours of local time, for example at 18:59:60 EST in Atlanta, Georgia.