A leap second is defined as an additional second that is inserted into human-made clocks—such as atomic time—to align them with solar time. The invention of leap seconds was needed due to a problem as old as time itself. On the eve of the first millennium, mathematician Al-Biruni split the length of days into 24 parts, which he later split into smaller time units using a sexagesimal system. This led to the creation of the second, which is equivalent to 1/86,400 of a day. Unfortunately, what Al-Biruni and other scientists did not know back then was that not all days last exactly the same. This disparity between day lengths has caused headaches to mathematicians, timekeepers, and engineers ever since.
Article
What are leap seconds and why do they matter
Leap seconds are needed to sync clocks with the solar time, but they also pose a challenge for streaming, OTT, and VOD platform developers.
The invention of leap seconds
The Earth rotates on its axis at 1,000 miles per hour (or 1,670 km/h), completing a day with a single revolution. However, the shifting core-mantle inside the Earth, glaciation events and changes in the magnetic field can alter—in the magnitude of milliseconds—the length of a day and thus the length of a second. In 1967, scientists worldwide agreed to change how seconds are defined by using the Cesium standard, this is the frequency in which radiation is emitted by the transition between two ground states of cesium. The name of this new standardized form of time measurement was International Atomic Time (TAI), which later became the Coordinated Universal Time (UTC).
Unfortunately, many systems were already using Universal Time (UT), which is based on the position of stars and the Prime Meridian. Slowly, UTC and UT clocks started drifting apart and by 1972 this disparity measured 10 full seconds. This led to the invention of leap seconds, which are added every now and then to keep UTC atomic-based clocks aligned with solar-based UT clocks.
Leap seconds have been added 27 times since their invention. The last time it occurred was December 31, 2016, and it caused havoc in servers around the world, affecting even big service providers. And it can happen again very soon.
When is the next leap second?
The next possible date for a leap second is June 30, 2023. Leap seconds have been added either at the end of December or June and are the responsibility of the International Earth Rotation and Reference Systems Service (IERS). In July 2022 the IERS announced that NO leap second would be added on December 31, 2022, with the next possible date being six months later.
Big tech companies have rallied against adding more leap seconds in the future. After experiencing an outage due to the leap second added in 2012, Meta declared in July 2022 that no more leap seconds are needed: “We are supporting a larger community push to stop the future introduction of leap seconds and remain at the current level of 27, which we believe will be enough for the next millennium,” Meta stated in a company blog.
Tech giants—such as Meta, Google, Microsoft, and Amazon—want to eliminate leap seconds as they do more harm than good in the age when websites, apps, and streaming services are used 24/7 and are used to deliver live content. Let’s take a closer look at the problems faced by streaming, VOD, and OTT clients due to leap seconds.
Why leap seconds matter in the VOD and streaming industry
Leap seconds represent a problem for the streaming, OTT, and VOD industries because they are hard for computers to digest. One of the principles of software architecture is to consider that time will always count forward, and if time stops or moves backward then glitches and crashes start happening. One example of this took place when a leap second was added in 2012, and glitches appeared in systems using the Linux kernel due to the lack of allowances for leap seconds in the base architecture of the kernel itself.
Computers communicate with each other through the Network Time Protocol (NTP), which ensures their clocks are synchronized to the millisecond. This is key for operations that depend on timestamps, such as purchases, stock transactions, and automated workflows. Three main problems in time protocols can happen due to leap seconds:
1. Communications or syncing ambiguity. If a system component is using UTC and another is using linear time, then errors can happen while sending instructions or syncing content. This issue is further increased if both reference the same time origin, such as the UTC epoch (1900) or Linux epoch (1970), or if one of the systems considers leap seconds while the other does not.
2. Playback errors. If a platform uses an API that does not consider leap seconds, many clients will calculate segment availability times that are later than the actual segment availability.
3. Erosion of client buffer. After a leap second occurs, the availability time is affected and impacts both the stream and all new sessions.
Additional issues may happen depending on the streaming technique implemented. While HLS does not use leap seconds (since it is not based on real-time), DASH can be affected by them since MPD time does not consider leap seconds. In the particular case of applications using the 2014 version of DASH, unintended behaviour can happen when using URLs directing to cached content. And if a leap second takes place during a live stream in a DASH client, the feed may advance or rewind the media in real-time. And since most leap seconds take place on December 31, there is a chance that New Years’ Eve programming (which usually includes popular live events) is impacted.
How streaming platforms can deal with leap seconds
Fortunately, the industry has experienced 5 leap seconds since 1999 and some good practices have been defined since. As mentioned above, a common glitch that broadcasters may experience with leap seconds is caused by incorrectly managing the duration and time of certain content. Some good management practices to avoid these inconsistencies and crashes are:
-
Ensure that both the service and client approach leap seconds in the same way.
-
Understand duration as the natural time length of a certain media.
-
Employ stopclock time to measure the duration of media.
-
Consider Google-style “smearing”, a common fix for leap seconds, starts when the additional second is inserted and time cannot be compensated beforehand.
-
Instruct the DASH player of your platform to sync its internal clock to one of the media servers to be perfectly in sync.
-
Make sure that the time of the platform accounts for any leap seconds that have taken place.
-
Use APIs and platform components that consider leap seconds while processing content, such as Axinom DRM and Axinom Encoding.
By following these recommendations, broadcasters can avoid crashes and schedule previously aired content reruns without having to alter the media timing or have issues with the time of media availability, which would be just re-based.
The future of leap seconds
In their proposal for the elimination of leap seconds, Meta mentioned an alternative called “smearing”, which splits the extra second across 17 hours to avoid forcing the systems to process an extra second. Although “smearing” might sound simple, its implementation is complex and needs to be worked into every system in-house, with Google being one of the few providers that offer to do it as a service.
Although the future of leap seconds is uncertain, there is no time like the present to evaluate if your content platform is vulnerable to the addition of extra time. This might be easier said than done, since as Linux founder Linus Torvalds once stated: “Almost every time we have a leap second, we find something. It’s really annoying because it’s a classic case of code that is basically never run, and thus not tested by users under their normal conditions.".
