Leap Seconds

When should we care about the leap second ?

The leap second removes or adds a second to the UTC date-time based on atomic clocks, to keep it it within 1/2 second of UT1 date-time based on the average rotation of the earth to the sun by astronomical observation. As the earth’s orbit is slightly oval, our direction to the sun at an average time of day varies over the course of the year. Our position is also slightly affected by the other planets, in a complex way over several years. Leap seconds help to keep these date-times aligned.

If you’re in financial services, it may matter if it happens during trading.

There are many kinds of financial transactions where you may only care about the day,
or an approximate cut off time. Other kinds of financial transactions which require recording to the minutes, and reporting to regulators within several minutes.
Of course, instant payments are being deployed, where payment settlement takes place within seconds. Then there’s high frequency trading with the possibility of thousands of trades per second.

A speaker at a blockchain seminar recently said how transactions were written about every 10 minutes or so, which makes it a somewhat fairer system than commodities trading. In financial markets, having your computers close to the exchange’s computers may give you an advantage in being able to execute your order ahead of competitors.

Trade and payment information gets distributed through a bank to lots of different software systems. Communication of the information is timestamped at each step through the process. Some applications may not handle leap seconds.

As leap seconds occur at the end of the day – in London – they may occur during a trading session in other parts of the world.

So what should you do ?

Make a choice whether your organisation should:

A) support leap seconds – use UTC NTP Time Servers
B) skip leap seconds – use UTC but pause activity but during the leap second
C) note leap seconds -use UTC, but round the leap second to the end of the previous second prior to distribution from the source system, and add a note with the actual sub-second time if required.

D) use another data time scheme

use UT1 or similar
use UTC-SLS = Smoothed Leap Seconds an internet draft.
use something like Google’s leap second smear

Some applications may require clock monotonicity – that is, they may expect the clocks to always go forward. There’s the issue of adjusting the system clock in use by the software.
When a clock is synchronised with a more accurate clock, it’s time may be adjusted forwards or backwards, so that events that occur later may end up having an earlier timestamp.

Once when I was investigating the reconciliation of several trades, I discovered that the clocks on the different trading machines were different by 20 minutes. Synchronisation had been turned off. It was easy to rectify this by turning synchronisation on outside of trading hours. If your operation is 24×7, or operates around the globe, you may want to consider how to keep events in order if clocks happen to drift beyond an acceptable variation.

For further advice or implementation, please contact us.