https://developers.google.com/time/smear#:~:text=During%20th....
- their (and probably others') distributed systems expect time to move forwards (synchronization, "happens after", etc)
- repetition of one second is difficult to accommodate for, e.g. with disk writes or storage of e-mail messages
- the initial leap smear was a hack/patch in their NTP servers by not setting LI (leap indicator), but modulating time within a window w before midnight:
lie(t) = (1.0 - cos(pi * t / w)) / 2.0
- leap smears eliminate the need for programmers to handle leap seconds
[2011]: https://googleblog.blogspot.com/2011/09/time-technology-and-...
(edit: list markup)
Time moves forward with both positive and negative leap seconds. With the positive ones, which we've seen before, we go from 23:59:59 to 23:59:60 to 00:00:00. Always forward.
With negative ones, which have not been seen in the wild, it goes from 23:59:58 to 00:00:00, skipping :59. Also always forward.
This confuses many applications. And ocassionaly confuses the Linux kernel, too [1]. Other kernels may have done better.
I think a negative leap second is less likely to cause the same sorts of problems. Otoh, it's never happened before, and leap seconds are generally not well tested.
[1] https://www.networkworld.com/article/711440/software-linux-i...
> Very large-scale distributed systems, like ours, demand that time be well-synchronized and expect that time always moves forwards. Computers traditionally accommodate leap seconds by setting their clock backwards by one second at the very end of the day.
Not quite "always forward".
Vote for me and I will also:
- Get rid of DST
- Put the whole USA on EST
- Take over the rest of the Americas and do the same for them (New York is basically centrally located as far as meridians go)
Smearing a single timezone over a four-hour-wide country works for China because the mean Chinese longitudial center of population is inline with Hong Kong/Shenzen/Wuhan; it's safe to say that almost all Chinese people live in the east. Comparatively, the US mean center of population is in Missouri. People in the far west of China already make use of unofficial local timezones precisely because the official timezone isn't designed to serve them; now imagine that behavior but applied to Los Angeles, the second-largest city in the country.
At best, you could split the US into two timezones that were two hours apart, with the cutover somewhere around the Colorado/Kansas border. But for optimal results you'd want to pull an India and make each timezone a half-hour offset from UTC, and at that point it's just too much bother.
Kinda like those systems that went down on Feb 29, 2024. I mean, how does an app in the 21st century not handle leap day? Yet it happened.
We'll always have programmers that have less than 4 years experience programming and hadn't even considered leap days when programming "This should happen every last day of the month" or whatever.
One would think libraries would catch this one way or another, but some people are hellbent at doing things their own way and then... Well.
Or, you know they considered it because they left a comment in their code like // TODO: Handle leap year LOL
Just as bad. Don’t roll your own time handling code.
A positive leap second gives you a discontinuous function from UTC to TAI. But a negative leap second means a function can’t exist at all, because the same timestamp in UTC now corresponds to two moments in time. If someone gives you a timestamp in UTC you can’t know which second it refers to - you would have to switch to giving timestamps in TAI.
A timestamp "repeats" to add a second (positive leap second). The subsequent timestamp sequence is delayed relative to its prior offset to TIA. The Google "smear" method works here to slow down the clock rather than repeat values.
To drop a second (negative leap second) we have a one second gap in the timestamp sequence. The subsequent timestamp sequence is advanced relative to its prior offset to TIA. This just requires a monotonic jump, as if the computer froze and did not perform any work for one second before resuming with the right clock values.
No, you cannot "just" do this in many instances. Some folks (especially in regulated industries) need to have a close link to UTC, and so purposefully smearing things would be non-compliant.
From my experience, stuff that needs serious synchronization does not care much about absolute time, and optimizes for very low relative offsets. Other stuff is OK with half-second or so in offset, and can tolerate much more.
[1] https://ec.europa.eu/finance/securities/docs/isd/mifid/rts/1...
Answer;
During the smear, clocks run slightly slower than usual. Each second of time in the smeared timescale is about 11.6 μs longer than an SI second as realized in Terrestrial Time.IIRC, there were some different strategies on how to modulate the length of the seconds. One method was to make all seconds in the 24 hours around the change uniformly longer; another was to increase second length slowly and then decrease slowly after the leap second. Either way, you'd need to do some math to determine when you were out of compliance, and if that overlapped with time you were operating where compliance was needed.
IMHO, better to not smear, and just not trade for a couple seconds around the leap second.
I don't usually "stand with google" on things, but I think this time I stand with google: better to smear, than invoke negative time and time repeats. If need be declare a trading holiday. Or, ensure the smear is within the compliance limits.
I don't see how you can be within 11.6 μs of UTC and also smear.
If UTC requires leap seconds in both directions (as it does) and your time keeping must be very close to UTC, you must keep leap seconds (this isn't too hard, historically FreeBSD has done just fine, although Linux has crashed a few times, and MySQL didn't like it at least once even if your OS was fine; other applications also had issues). And you've got to figure out how to log :60, rather than :59 twice; this is probably harder.
Personally, I'd vote for all seconds be the same length, and all days the same number of seconds, and all days the same number of hours. Maybe ocassionally redefine time zones, until the seconds per day is really off. But you know, the powers that be insist that UTC stay close to UT1, and DST is a thing too (different orgs, but still messed up)
I've yet to see anyone who seriously tried to be compliant both to the spirit and to the letter of MiFID. It's both hard and expensive to the point where the fine expectancy might be lower than implementing costs. Everyone do just enough to plausably deny they're not compliant.
We had multiple levels of recording, the last resort was really storing raw pcaps of trading recording.
Very expensive.