"ISO" is the International Organization for Standardization, in English, Organisation internationale de normalisation in French, and Международная организация по стандартизации in Russian, its three official languages, as one fairly well-known example.
The decision was made by representatives from governments worldwide at the General Conference on Weights and Measures (CGPM) outside Paris on 18 November.
I wouldn't be too shocked if they asked "what uses leap seconds", got an answer, and are advocating on that basis ("We have systems that use leap seconds!"), without having actually asked better questions like "What would require expensive changes if no more leap seconds were issued?"
I think the commenter means that there isn’t a technical reason that GLONASS can’t be changed to not add leap seconds not that Russia doesn’t have to defer to an international body.
This is surprising to me. Is the Earth's rotation so arbitrary?
The more precise you want to be, the more complex and numerous physical phenomena you need to consider become; with a system as involved as the Earth, at some point you get to weather-like chaotic behaviour, so no practical amount of additional precision in input data helps anymore.
The earth even speeds up and slows down in response to stuff like earthquakes and volcanoes.
It is really convenient that the date changes whilst we all sleep. It makes 'today' and 'tomorrow' weird.
https://www.bipm.org/documents/20126/64811223/Resolutions-20...
https://www.forbes.com/sites/jamiecartereurope/2022/08/03/do...
Also why does it say the earth is slowing down but this year it sped up. Sounds quite impossible?
Edit: TLDR; Local maxima vs. overall trend.
Oh wait, that's not how it works. And neither is it how leap seconds work.
Leap years have to do directly with the sun, what day and time the equinoxes happen every year and the like. This time noticeably drifts every year, even every day, computers or not.
These leap seconds and what not have to do with very sensitive instruments measuring time very precisely. These time measures are entirely about machines.
Only the madness of "smearing seconds" and other workarounds for broken software with incorrect calendar implementations makes them seem different.
Does that sound bananas to you?
Of course it is. That's what we're doing with leap seconds. Only some people smear and some people leap and they don't even do it over the same time or in perfect synchronicity.
Just ditch the leap seconds. They are not worth the cost.
Move what is leapsecond independent to UT1, the atomic clock basis -- google, finance, etc now happy
Keep UTC etc as is, since offests happen all the time to every other human clock anyway for political or summer time or country boundary changes anyway -- everyone else happy
And calculating UTC as offests from the consistent base of UT1 sounds like the way to do it
In years to come historians will be having a good old chortle about how we managed to come up with two times that were 37 seconds apart.
In retrospect, fiddling with computer clocks like that was bound to be a nightmare.
https://www.newscientist.com/article/2344401-annual-us-clock....
The great leap-minute crisis of 2147 will be interesting.
We may not care anymore, but emphasis on may.
Of course, that’s an absurd interpretation.
So it's totally true that no one is actually mislead by this, but I absolutely understand those who try to pretend they are, and have a slight disdain for those who try to defend this bullshit.
There's maybe an argument to be made that using language which implies the legitimacy of organizations as presenting "all of us" is a sort of supremacist way to act, because it casually legitimizes whoever happens to be in power without questioning where they got that power or whether they earned or deserve it.
But, like, it's a standards body. If the world didn't have one it would want to go and make one and then be back where we started. This isn't the interesting battlefield for that kind of point.
When the previous leap second was applied, a bunch of our Linux servers had kernel panics for some reason, so needless to say everyone was really concerned about a leap second happening during trading hours.
So I was assigned to make sure nothing bad would happen. I spent a month in the lab, simulating the leap second by fast forwarding clocks for all our different applications, testing different NTP implementations (I like chrony, for what it's worth). I had heaps of meetings with our partners trying to figure out what their plans were (they had none), and test what would happen if their clocks went backwards. I had to learn about how to install the leap seconds file into a bunch of software I never even knew existed, write various recovery scripts, and at one point was knee-deep in ntpd and Solaris kernel code.
After all that, the day before it was scheduled, the whole trading world agreed to halt the markets for 15 minutes before/after the leap second, so all my work was for nothing. I'm not sure what the moral is here, if there is one.
> He went away from the basement and left this note on his terminal: "I'm going to a commune in Vermont and will deal with no unit of time shorter than a season."
[0] https://en.m.wikipedia.org/wiki/The_Soul_of_a_New_Machine
– Seemingly simple tasks can be more complex than you expect (“add a leap second on this Wednesday”)
– Real world systems can be more complex than you expect (“bunch of software I never even knew existed”)
– Planning and testing can make a big difference vs. just winging it (“a bunch of our Linux servers had kernel panics for some reason”)
– Success can be a non-event that goes unnoticed (”everything worked and no money went missing”)
– Sometimes the best solution is not a technical solution (“halt the markets for 15 minutes before/after”)
We've had an election recently, right on the day when DST changed. On the night of counting of the votes, the clock went 2:59 AM -> 2:00 AM.
To save themselves trouble the Statistics Office instructed all vote counters that under no circumstances are they to enter or update anything in any system during the repeating hour until it's 3:00 AM the second time…
I once came across an early 1950s Scientific American article by Bertrand Russel, IIRC. It included a cartoon.
Frame one: Computer beats man at chess.
Frame two: Man unplugs computer.
And yet, there are still Y2K deniers (to be fair some people have exaggerated it to the point that they're promoting it as the end of the world).
I'm little confused. How does this solve the problem? If you don't code for the second, you'll still be off if you wait. I'm I missing something?
It always pays to not be the least-prepared among your cohort. You'll get no sympathy if you're at the back of the pack, you'll just die.
This is a hugely valuable learning experience few people even get a chance at, let alone solve. Too bad it doesn’t show up on your resume is the only downside!
Interview discussion? If you're any good at interviewing, it should.
...okay yeah that's not a moral, but still.
$work had thousands of full custom, dsp-heavy, location measurement hardware devices widely deployed in the field for UTDOA locating cell phones. It used GPS for time reference -- if you know your location, you can get GPS time accurate around the 10's of nanoseconds. GPS also broadcasts a periodic almanac which includes leap second offsets: if you wanted to apply the offset to GPS you could derive UTC. Anyway there were three models of these units, each with an off-the-shelf GPS chip from one of three location vendors you've probably heard of. The chip firmware was responsible for handling leaps.
One day, a leap second arrived from the heavens. We learned the three vendors all exhibited different behaviors! Some chips handled the leap fine. Some ignored it. Some just crashed, chip offline, no bueno, adios. And some went into a state that gave wildly wrong answers. After a flurry of log pulling, debugging, console cabling, and truck rolls, we had a procedure to identify units in bad states and reset them without too many getting bricked.
It seems the less likely an event is to occur, the less likely your vendor put work into handling it.
Idle curiosities can lead to their own waste, but the kernel panic was probably worth digging into earlier.
Apparently, its about as useful as the leap second itself ;)
I feel your pain though, as I've spent weeks on something only for it to be tossed away like it was nothing at the last second. I guess that's how Google devs feel when their projects are deprecated. At least theirs saw the light of day and provided some validation
It is clear to me that the disparity of latency creates islands of privilege. I mentioned this to someone in the industry once and they replied that what the layman perceives as parasitic middlemen actually provide valuable liquidity. When I asked whether they considered ticket-scalpers to likewise provide liquidity they claimed that was not at all the same thing.
I think the moral is that it'd be a lot easier if we could just stop messing with the clocks, or at least push more technical things towards only caring about a closest-to-a-global-high-precision-monotonic-clock-as-relativity-allows rather than worrying about what the clocks on the walls say, which is more a personal matter of how much you care or don't where the sun is in the sky at 12:00:00.000.
Edit: I guess the other way to look it is I guess now how much you can make on a few minutes of trading, seeing that it was worth putting at least one software engineer on it for a long time despite the risks...
As the CIA director in Burn After Reading says, "I guess we learned not to do it again."
So his work contributed to community wisdom, and that influential community has probably had some say in cancelling leap seconds. I wouldn't call his work wasted. I would call that notably few degrees-of-separation in making an observable difference.
Always procrastinate :-)
Sometimes the best (for some definition of best) solution to a problem is to side-step it entirely.
You're conscientious and willing to dig in to the details to fix a problem. Plenty of people aren't, and plenty of those are doing the same job as you. Look up from your own little world and try to figure out what other people are doing, how they're doing it, and why. This applies generally: If you fixate on a specific language or toolkit, you'll miss others which fix or obviate bugs you were resigned to living with. Same with OSes and environments. It even applies to relationships, which is why a big hallmark of abuse is isolating the victim.
Do you mean at your desk? What is a lab in a fintech context?
If we kick the can down the road such that eventually we'll need to add a leap minute, we're going to end up with software that was never written to expect time to change in such a way, hasn't had a real world test of the change for decades, and will have no one working on the software who ever had to deal with such a change.
It's going to be much worse for software reliability to have a leap minute on the order of once a century than a leap second every few years.
Storing anything as UTC was a mistake and we should be using TAI for all storage and computation, only transforming into more human friendly formats for display to end users. This never needed to be a problem except we decided to make it harder to use TAI than UTC and so everything got built up off the backs of legacy bios level hardware supported UTC style clock behaviour, when we should have been using TAI from the start. Yes I know it would have been harder, but we got off our collective asses and decided to fix our short sighted decision making for Y2K date storage, why not this… if it truly costs as much for everyone to endure a leap second why wasn’t it just fixed from the bottom up and rebuilt correctly!
So, in one century, we'll get 1 minute's worth of drift.
Recall that we all share the same clock within timezones, and 1 minute of drift between atomic & solar clocks is the equivalent of traveling 1/60th of your timezone's width to the east or west ... something many people do every day as part of their commute. _Everyone's_ clock deviates from their local solar noon, and _nobody cares_.
Put another way: (at most) one north-south line in your timezone will have solar noon & clock noon line up. Over time the relative location of that line will move. Fine. Let's not screw with our clocks in an effort to keep the location of that line fixed.
Leap seconds are a solution in search of a problem.
I find this off-hand comment dismissive and out of touch. The semi-annual switch from Daylight Savings to "normal" and back again is absurd, and far from not affecting anyone. Studies show that productivity drops for about a week following the change [1], and there is a marked increase in road fatalities after the clocks are adjusted [2].
If anything, this leap second business is what's irrelevant to everybody except a handful of obscure boffins.
[1] https://www.healthline.com/health-news/daylight-saving-can-m...
[2] https://www.boston.com/news/jobs/2016/03/16/daylight-saving-...
it happened again to me just a few weeks ago with the DST switch. i was so mad when i learned that everything had felt off the day of the switch because it was off that i just set all my clocks to UTC. no more gaslighting: my clocks all accurately measure intervals with no tricks, which is exactly what i most want out of my clock.
[…]
> The CGPM — which also oversees the international system of units (SI) — has proposed that no leap second should be added for at least a century, allowing UT1 and UTC to slide out of sync by about 1 minute. But it plans to consult with other international organizations and decide by 2026 on what upper limit, if any, to put on how much they be allowed to diverge.
So everything about this hasn't quite been sorted out yet.
At some point there may need to be a reckoning like was done with the calendar:
> Second, in the years since the First Council of Nicaea in AD 325,[b] the excess leap days introduced by the Julian algorithm had caused the calendar to drift such that the (Northern) spring equinox was occurring well before its nominal 21 March date. This date was important to the Christian churches because it is fundamental to the calculation of the date of Easter. To reinstate the association, the reform advanced the date by 10 days:[c] Thursday 4 October 1582 was followed by Friday 15 October 1582.[3]
* https://en.wikipedia.org/wiki/Gregorian_calendar
As annoying as handling a leap second could be, if it happens even somewhat regularly it can be testing more often. Deciding in the future to do a 'one-off' event may be more challenging from both a coördination point of view, as well as trying to handle a rare event correctly in (e.g.) code.
To quote the relevant section:
> [the CGPM] decides that the maximum value for the difference (UT1-UTC) will be increased in, or before, 2035
> [CGPM requests that the ITU] propose a new maximum value for the difference (UT1-UTC) that will ensure the continuity of UTC for at least a century
I think there are a few possible interpretations of this:
- We'll readjust UTC in a century (why would you do this to yourself, please no, nobody wants this) by setting a predicted maximum that'll last 100 years
- The maximum is now 1 hour, we'll adjust clocks the same way we adjust for DST
- The maximum is infinite, UTC is now TAI + the same integral offset forever
I'm hoping for the last one, but who knows. They've once again kicked the can down the road to the next 2026 meeting to decide what the increase in max UT1/UTC difference will look like.
Our current calendar was introduced in 1582, 440 years ago [0].
We add a leap second about every 1.5 years [1].
That means in the time since our calendar was invented, we've added less than 5 minutes to our time.
Would anyone notice if noon arrived 5 minutes earlier over the course of 500 years? Especially since the position of the sun varies orders of magnitude more than that simply based on season?
Maybe we could all just agree to add 10 minutes in 3022. If we haven't switched calendars again.
[0] https://en.wikipedia.org/wiki/Gregorian_calendar [1] https://www.timeanddate.com/time/leapseconds.html
Anybody who cares about leap seconds should have just been using TAI all along instead of UTC anyway.
standardizing leap smearing algos and constants could work
-Bottom layer is atomic clock seconds -We define targeted relationship between current UTC and atomic counter that will occur on a given day and time X -Time is interpolated to drift UTC into place by the given day and time X -Standards body can adjust time on some regular basis by its relationship to the atomic clock and publish the algo to convert from atomic to UTC
Each leap second event causes hundred of millions of dollars worth of disruption and that's not including the disruption created by leapseconds even when they're not happening (e.g. the frequent false leap seconds) or the mini-disaster we're sure to experience should there be a negative leap second (which we are still trending towards).
The delays are unfortunate because it's harder to transition applications that need UT1 to use an offset from UTC when the available time sources are still unpredictably and unreliably leaping on you (since to apply a UT1 correction you need your UT1 offset and your UTC source to agree if and how a leap second has been applied).
From a practical perspective it would be better to immediately discontinue leaping, then UTC would immediately become a stable time that adjustments could be applied against for those few applications that need them. It would also save us from a negative leap second.
Yah, one second doesn't matter, but it builds up.
This: "Or we could even decouple our sense of time from the Sun entirely, to create a single world time zone in which different countries see the Sun overhead at different times of day or night."
Shows that they are completely disconnect from human reality: "Science already doesn’t use local times, we talk in UTC."
That's great for science, but people care about day vs night.
There's an exact time everyone knows the correction will happen, it's just a question of how big the correction will be.
The correction is always in the same direction -- no "one second forward, then later one second back" shenanigans.
It always happens over a weekend, so no one has to deal with real-time work-time issues.
While maybe some have to work a weekend, at least it's not near the year-end holidays.
It only happens once every 100 years.
A very interesting idea, but probably much too progressive.
I believe I just fell in love with that idea. If this would become a social norm people would maybe stop trying to reach me in the morning.
And I would know if it's too late to call others.
In 1972 it was decided that the best way to compensate for this is to insert (and sometime remove) leap seconds, so that the difference between UTC and Earth’s rotation is kept below one second. A certain subset of astronomical and navigational/satellite applications rely on that condition being true. If this is changed, some decades-old systems, some of which may be critical infrastructure, may have to be substantially modified to account for leap seconds in some other way. The mention of GLONAS in the article is one such example.
In the international standard body responsible for UTC (ITU-R), there was up to now no sufficient majority in favor of abolishing leap seconds, due to those concerns. (Never change a running system, so to speak.) By now it has become apparent that the benefits of dropping leap seconds should vastly outweigh the potential drawbacks, at least for the next few decades. But it took some time for that realization, and probably also some older participants whose minds couldn’t be changed to die off.
GLONAS and other GPS like systems already have to deal with the temporal effects of special AND general relativity in their time keeping. Pushing leap seconds off on to the already special case system seems like a fair trade for making every other programmer and sysadmins life easier. let the extreme corner cases deal with their problems not everyone else.
So, I had limited time manipulation capabilities. I tried to write all the date handling stuff by hand (with a lot of "if" statements for the special cases). I recall trying to make leap seconds work, but not sure if I actually did. It worked well enough for my purposes.
Also, no database, so I did it all with flat files. Worked better than you might expect (thanks to built-in flock()), but I wouldn't recommend it.
power prefix symbol
10^27 ronna R
10^−27 ronto r
10^30 quetta Q
10^−30 quecto q
If we decide that we absolutely need to keep our time in sync with the rotation of the earth, really what should be done is define a timezone with all the leap seconds applied, and use that timezone to only display it to the end user. Not change the way we sync computer clocks for no reason! NTP shouldn't contemplate leap seconds, for example...
The cost/benefit at the time didn't look so bad because the world wasn't full of distributed synchronized computer systems, so the added 'cost' of leap seconds was just some make work for geeks in national timing labs.
The cost benefit is very different today.
We can keep civil time roughly aligned with the sun by moving timezones an hour every four to five thousand years.
Applications that want to give accurate sidereal time or very accurate sun-up sun-down can use predictions of UT1. Bonus: it's a lot easier to give an accurate UT1 when you don't have to worry that leapsecond (mis)handling has screwed up your underlying clock.
That's another part of the cost model that has changed: When leap seconds were created it would have been burdensome to carry around an additional offset in time transmissions for those few applications that want a more accurate mean solar time. But today its fairly easy.
Afaik the most vocal opposition to reforms came from the US
[1] https://en.wikipedia.org/wiki/World_Calendar
[2] https://en.wikipedia.org/wiki/International_Fixed_Calendar
[3] https://en.wikipedia.org/wiki/French_Republican_calendar
Eventually, thousands of years from now when time has drifted by an hour or more (assuming modern technological civilization even still exists by then), each jurisdiction can just change their time zone's offset from UTC, without coordinating with anyone else. Jurisdictions making time zone changes is a well-understood situation that we already know how to deal with.
Leap seconds are an architectural blunder that always belonged in the abstraction layer that lines up the sun with the rotation of earth (the time zone abstraction). It never belonged in the part that counts seconds.
Thanks to glaciers melting, earth rotation is (temporarily) accelerating. Because of that, positive leap seconds, regular before, didn't happen since 2017 - so there could very well be (recent) software out there that has that code-path broken, and nobody noticed yet.
And due to exact same geophysical effect we might see a negative leap second - something that never ever happened before. What are the odds that every single piece of software gets that one right?
Be interesting to estimate the size of the various effects (no doubt I've missed plenty of others) but is it really true that a change in sign of the acceleration of Earth's angular velocity is down to climate change?
Even over thousands of years when an hour of drift is accumulated there won’t be a manual adjustment - people will have just gotten used to different times of day having sunlight, with generations having been born and died with mean solar time happening at 11am.
Eventually the rotation of the earth may change enough that drift accumulates too quickly and leap time needs to be added, but that’s only going to be true thousands to tens of thousands of years in the future.
That'd test all the software paths.
The daylight savings time bugs I've run into at pretty much every company I've ever worked at would beg to differ.
So this isn't a once-a-century thing, it's adding-a-leap-15-minutes-once-a-millenia issue.
Odd. I was wondering how fast it actually was long term, and this rate from historical record seems much lower. They cite 1.8ms/century if I'm reading it correctly with some odd cyclical thing going on. " the change in the length of the mean solar day (lod) increases at an average rate of +1.8 ms per century. "
I mean, we've added 22 seconds over 50 years. Although at current rate it would still just be 7 minutes after a millenia :)
edit You know, nevermind, that's all covered on wikipedia. https://en.wikipedia.org/wiki/Leap_second#Slowing_rotation_o...
Plenty is not.
The Swift time type ignores them in its implementation. I filed an issue, and they said there were no plans to implement them.
Good choice it turns out.
Who would of thought that adding a second on random new year changeovers would be worse than letting clocks drift.
Me for one.
We can have a "leap hour" in a thousand years. Till then do we care, I do not, if the clocks and the sun drift very slowly apart from each other?
I can just imagine Graybeards of the future rushing ahead of the leap minute to update the JVM lest the world goes in flames yet again.
Earth's rotation relative to the Sun is whole another deal.
- the measurement of durations.
- the presentation of some timestamp in a way that the reader has some intuition for.
that first purpose won’t be hurt by not tracking leap seconds. actually, a lot of applications will probably more accurately measure durations by eliminating leap seconds.
if leap seconds (or minutes) really are of critical importance, we’ll reintroduce them to the presentation layer. the thing is, very few people can tell the difference between 12:01 and 12:02 without being told the “real” time. so if you’re presenting a time which is “off” by a minute because there’s no leap seconds… does it really matter?
1) Seconds since 00:00:00UTC 1.1.1970. This value increases by 1 each atomic second and never goes forward/back. Call this Universal Monotonic Time.
2) The difference between when the sun is at its zenith at Greenwich and 12:00 UMT. Call this the Astronomic Drift.
3) The timezone - offset from Greenwich that makes the local clock sync up with astronomic time and also contains a DST offset if that location observes DST at that date.
By adding up 1) + 2) + 3) you end up with the "human time" at a given location at a given date.
A computer system should only ever store 1). Then, it can calculate human time when displaying it to humans.
I'm also a fan of having "local sun time" which would be the time according to the position of the sun in the sky, quantised to 15-minute slices (basically micro-timezones). It would be nice if office hours, school times, &c can be defined based on that, i.e. work starts at 9am local sun time, which will sync up better with people's biological clock and cut down on the yearly stress DST causes.
>If we kick the can down the road such that eventually we'll need to add a leap minute
The drift is not in a single direction. The total drift is not going to be significant for a very long time if ever.
That doesn't stop the (e.g.) FreeBSD folks run tests to make sure things are fine:
* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...
* https://docs.freebsd.org/en/articles/leap-seconds/
Of course there's a whole lot of other userland code besides ntpd.
The point is, that there ALREADY EXIST both TAI and UTC. TAI is true monotonic (whatever it means in a relativistic universe) and doesn't make any compromises. UTC abolishes monotonicity in order to keep both the length of a second and the time relationship to the orbital rotation. They both work. For whatever reason (for obvious reasons that is, but doesn't matter) UTC was chosen in virtually any software system to keep time.
So, ok, if there is a suspicion of leap seconds being unnecessary. How about moving from UTC time to TAI then? Let's keep UTC as it is, keep adding leap seconds and just make it a best practice to rely on TAI for all datetime operations and world clock synchronization? Maybe it will work out, maybe it won't, but at least you won't be breaking a perfectly working alternative (currently — mainstream) system.
The more I think about it, the more outrageously stupid abolishing leap seconds seems.
If they weren't going to do that, then why eliminate leap seconds? Kicking the problem down the road doesn't really solve the problem, it just makes it worse later.
What was chosen really isn't UTC. Several UTC seconds in the past are not accurately representable in unixtime. Several unixtime seconds in the past are ambigious as to which UTC second they are.
Unixtime is awfully close to UTC time, but it's not the same. If UTC time stops inserting leap seconds and never has negative leap seconds, then they will be equivalent going forward.
They are recommending TAI for storage, compute, and not against UTC for human consumption
Although the easier hack: Abolish leap seconds from UTC!
Original comment: Only those who never tried to actually use TAI yourself can claim that you can use TAI instead of UTC without a problem.
That won't break anything...
I'm not sure why we don't define an intergalactic time standard and approximate that everywhere with NTP-like protocols; one monotonic clock at rest (with respect to CMBR) in free space. The second is weirdly defined/tracked in Earth's gravity well.
As long as the Earth exists and you can communicate with people there, there's no practical reason not to use an earth based reference clock.
The clocks that were used to build TAI (its a co-ordinated average of dozens of atomic clocks around the world) became sufficiently accurate that the difference in each second based on the altitude of the clock measuring it in the early 70s. As a consequence of this it was decided that as of 1 January 1977 00:00:00 TAI would be corrected to correspond to what TAI should be if measured by clocks at the geoid (mean sea level) and as a result it has no relation to altitude or accelerations. There is also (because metrologist are like this sometimes) a continually published version of what TAI was before 1 January 1977 00:00:00 but it is now named EAL (Échelle Atomique Libre, meaning Free Atomic Scale)
In addition to this, we have already designed and maintain equivalent time standards to TAI, but for the Earth's barycentre Geocentric Coordinate Time (TCG - Temps-coordonnée géocentrique) which is roughly speaking TAI for a clock orbiting the sun, where the earth moon barycentre orbits, but without the earth & moon gravitational influence... and for the entire solar system Barycentric Coordinate Time (TCB, from the French Temps-coordonnée barycentrique) which is roughly speaking again, equivalent to a TAI style clock but this time subtracting the entire solar system, as if a clock keeping TAI was just orbiting the galaxy at the barycentre of the entire solar system.
The cutting edge of this is building up astronomical data on ultra stable pulsars to use as "external" reference clocks far outside the solar system, but the complexities of subtracting the effect of all the universe the pulsars' radiation beams pass through before they get to us, makes it quite challenging. But the utility for deep space navigation has made it an active funded path of research for at least the last decade. (to get a GPS equivalent at lunar distance and beyond where it becomes rapidly impractical to have a GPS like orbiting constellation due to inverse square radio broadcast power limits, good radio can pick up GPS at the moon but the location precision out at that distance... is not great)
The cosmic microwave background dipole may be indicative that we can use it as an absolute frame of reference but settling that with enough certainty to base an official time standard on it, seems like some time away based on the state of things between cosmology, astronomy, astrophysics and metrology.
> more human friendly formats for display to end users.
This is what's doing the very heavy lifting in your proposal. Leaving aside not knowing when future leap seconds will occur (and thus getting mismatches when broadcasting to different computers that may or may not get the information about the leap seconds at different times) the sheer fact of the matter is that software developers are users too. They will take shortcuts and display TAI as UTC because "something, something people are lazy or uneducated."
We do not need leap seconds. We never should have implemented them. They are a scar on our software for potentially hundreds of years already for any application that seeks to have high accuracy over time.
Time is very frequently a join key or part of a join key in a database and these small differences mean countless hours wasted to investigate "couple of record" mismatches.
Just stop using leap seconds. We will be fine.
What applications and date-time libraries should really do is differentiate between timestamps, calendar plus wall-clock time, and elapsed runtime. In most circumstances, only the latter would really need to be consistent with TAI.
The straight up truth is that we created something in between. Some parts of earth sun alignment are in the time zone abstraction layer and leap seconds are in the seconds count layer. There's no real cause for this and we should have moved to TAI to fix this blunder long ago.
EDIT: info below is incorrect about UTC not being monotonic, as pointed out in thread but is useful for monotonic vs non-monotonic:
In UTC you can jump forward or back, so it's possible to do an operation after another operation but have a timestamp before it, which is bad for many reasons, top being auditing.
do operation one at T0 do operation two at T1 do operation three at T-1
in TAI it would always be do operation one at T0 do operation two at T1 do operation three at T2
How do you add a full day, if you do not know whether a leap second occured or not?
I had to look up TAI. I disagree. UTC exists for a reason. But I am here to tell a war story.
Before I arrived on the scene a customer said they wanted local time in the reports. (As in Wall Clock Time).
The Customer is Always Right. OK?
So the times went into the database as wall clock time.
The designers of the data schema made a simplifying decision to store everything as text.
No time zone went into the text string that described the time. (?? I do not know why. So easy it would have been)
I come along and have to code animations using that time series data.
Very few problems...
As you would expect there are a lot of other problems with that database.
And the leap year problems of the Julian calendar weren't a problem… until they were. And then good luck coördinating things:
* https://en.wikipedia.org/wiki/Gregorian_calendar#Adoption_by...
* https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale...
The actual Unix time does not change when the clocks are switched between daylight saving time and standard time. Only the time zone changes.
When a leap second occurs, the actual Unix time changes, which can lead to bugs, e.g. when a positive time difference comes back as negative. To prevent such issues, a monotonic clock can be used to measure time intervals.
I'd argue there should be no adjustment until it gets to be +- 15 minutes from UT1. And even then, NO clock skewing, just a time zone adjustment across the board.
We already rejigger the time zones from time to time, so thats already handled. It's still a source of issues, sure, but it's once source instead of two.
The timezone rejiggering could also be set hundreds of years in advance... rather than the very short notice we get for leap seconds.
just build a planetary motor.
encircle the earth with ferromagnetic coils, then fire asteroids (similarly banded) at the earth in a series of near misses the magnetic drag steals or imparts angular momentum depending on the direction of the asteroid relative to the earth.
Like I said: it could become a huge coordination problem.
* https://en.wikipedia.org/wiki/Gregorian_calendar#Adoption_by...
* https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale...
UT1 - based on Earth's rotation only, strictly 86400 seconds per day; length of each second varies; takes a heck of a lot of effort (and time) to measure accurately.
UTC - has same length of a second as TAI, but (for now) tracks UT1 to a precision of +/- 1 second. To achieve that, can have days that are 86399, or 86400, or 86401 seconds long.
None of 3 is planned for scrapping. The only change discussed in TFA is to fix UTC day to 86400 seconds (at cost of letting it drift further away from UT1).
As the article said, many countries jump forwards and backwards an entire hour twice a year and after the adaptation period we don't notice
We (or our descendants) can try to fix Earth rotation. All is needed is a big enough rotating mass with a variable speed of rotation.
We would use UTC. UT1 would end up only being used by astronomers and whoever else cares about the Earth's rotation.
By the time UTC and UT1 diverge enough to matter, humanity will have either destroyed itself or come up with a new time standard.
Astronomy commonly uses TAI or raw GPS time. In fact if you look at video footage from NASA control rooms and such there's usually a GPS second clock up on the wall somewhere.
The motivation for leap seconds wasn't astronomers, but to just keep civil time tied to solar time long term. However, the unpredictability of these leap second additions has proven to be pretty annoying, causing bugs and such. This is why google and others actually "smear" the introduction of their leap seconds over half the day.
Considering the current difference is 37 seconds, its natural to wonder if this is worth it. Certainly most people wouldn't notice relative to dawn dusk for a very long time, long enough that the entire concept probably wouldn't even make sense anymore. So why not just stop? That's the basic argument here.
It seems like JPL (NASA) and the scientific community have defined two currently used sets of time standards for observations from Earth and from space near Earth. https://en.wikipedia.org/wiki/Time_standard#Time_standards_f... Barycentric Coordinate Time (TCB) and Geocentric Coordinate Time (TCG) with DE430 as the current revision of their standard https://en.wikipedia.org/wiki/Jet_Propulsion_Laboratory_Deve...
Look at astronomical software, e.g. xephem. There will be a "clocks" tab that displays a number of different clocks, TAI (atomic clock, no leap seconds), UTC (global civil time), media solar time (GMT, which ISN'T UTC) and finally, derived from the aforementioned "sidereal time", which is the one you really need to adjust your telescope. Sidereal time is derived from a year with 1 more day basically, because the earth moving around the sun adds 1 more rotation of the background stars. Which is a drift of roughly 4 minutes per day.
https://en.wikipedia.org/wiki/Sidereal_time
Oh, and then there is stuff like Julian date which you need to look up the myriads of catalogues and tables you need for corrections because everything "wobbles" even more than you'd think.
Yes, dropping leap seconds will remove 1 table lookup from the above. But astronomical time systems are so complex that that change is a drop in the ocean.
For sophisticated astronomy systems the elimination of leap seconds should simplify and reduce a source of errors. As it is, since Circular T is against UTC you need to take your local source of time and worry if leap seconds have been correctly applied (apply leap seconds to gps time or make sure haven't been fed smeared NTP time or other horrors) before you can get UT1.
Fairly casual astronomy, no-- but that isn't driving international standards, and there mechanical uncertainties dominate so you'll end up doing a 1-star correction in any case which immediately corrects the clock.
E.g., suppose you made a system where each satellite transmits messages of the form "Here comes beep #N. At the time of beep #N this satellite is at this position: <X>, <Y>, <Z>. Here is beep <N>: BEEP!".
The satellites are synced so that beep <N> occurs at the same time on all of them.
By looking at the time difference between the arrival of beep <N> from several satellites a receiver could tell the differences between its distances from those satellites. Combined with the position information for those satellites at the time they beeped the receiver would be able to tell its location.
If the satellite broadcasts use a high enough frequency and that frequency is known and very stable the receiver would not even need an accurate stand alone timer. It could sync a counter to the frequency of the satellite radio.
I don't think it's that big of a deal; do you really care what the perception of "11 in the morning" is for someone 1,000 years ago? This kind of thing is pretty cultural anyway, and a slow drift over a thousands of years doesn't really matter.
The main reason we have the "new" Gregorian calendar is because of religious reasons, not because people were having huge practical problems with the old (slightly less accurate) Julian calendar.
Plus the current leap second system won't really deal with the long-term drift anyway because the earth's rotation keeps slowing, so in a few hundred years we'd need more leap seconds than the current system allows, and eventually we'd need a "leap second" every day because the day is a second longer (around the year 6000 IIRC).
It just so happened that the religious authority in the West was able to make a significant change to the civil calendar which also happened to match the Church calendar, and it was adopted by all of Christendom, eventually even Asia and the four corners of the Earth have accepted it as universal and not so religious.
Less than you think. A part of the leap second is correcting an unpredictable random walk. The random walk part does not add up.
The linear drift part does add up. We're still talking several thousand years to end up with just an hour offset.
Just switching to a new timezone every few thousand years ("As of Jan 1st 6022, fifty years from now, all usage of Eastern timezone will switch to New Eastern timezone, which is an hour ahead.") would handle your civil usage concern fine.
(and then in year 10022 they can switch to New New Eastern timezone, if there are any survivors of world war 5...)
I think this goes along the lines of the great DST debate, the US is going to do away with the changes next year and make DST permanent. Not do away with it, keep it, forever.
Fundamentally we create these abstractions and begin to rely on them and then decouple how we operate from the real world. We created the clocks to measure the position of the sun in the sky, now we ignore the sun entirely, the clocks are god now. I don't think it's a good thing generally speaking, but on this particular issue, I don't think people are going to really feel anything different happening, it will decrease the engineering burden to constantly maintain and update systems, which means decreased resource consumption, with no noticeable impact on the day to day lives of anyone except those engineers relying on exact time measurement.
This is obviously better, when you save a file for example you don't care about the region of the user, and thus the save timestamp of the file should really be an absolute number, so if you take your laptop and go from one country to another your whole system doesn't break because it sees timestamps in the future, same thing when daylight saving is applied and the clock is brought back/forward by an hour.
Leap seconds, if we decide that we should keep them (to me not, because the difference is so little that we would start to notice that in centuries, and who knows not which computer systems we will have but if humanity still exists), should really be handled at time zone level, by shifting of an offset that contemplates leap seconds, and not by slowing up/accelerating clocks.
Today, the solar meridian in Madrid is at 12:59 PM, while the solar meridian in Belgrade is at 11:23 AM. This is because Madrid and Belgrade are within the same time zone, in order to more easily coordinate European commerce.
If that's an acceptable tradeoff, I don't really see the issue in drifting something on the order of dozens-to-hundreds of seconds per century.
They had done it all the previous leap second during the weekend.
The hard part that required a lot of work was making sure that nothing breaks when it happens.
In this case they chose to have a mini weekend in the middle of the week for convenience
This variability will provide excellent fuzzing of all time libraries everywhere.
The point still stands though - common problems have tested code, uncommon/rare problems rarely have battle-hardened solutions.
You can hear that unixtime is the number of seconds passed since X. But it isn't really true though. The number of seconds is number of seconds, it isn't defined by our standards, it just exists. And TAI is a fair representation of how many seconds on Earth actually passed (on average) since whatever.
UTC kinda does it as well by virtue of 1 second being equal to 1 TAI second, but it actually counts (counted until yesterday) the number of Earth's rotations. It's just every rotation (represented by 24H) sometimes consists of more than 86 400 seconds.
Unixtime on each individual device counts nothing. It imperfectly represents UTC timestamp received over NTP. Some timestamps are represented twice by the same value. Of course, you can just put your device offline and call it "unixtime" whatever number of seconds it counts since any moment, but you know it will drift away from any meaningful "real" time soon enough.
(Also, it's not even entirely fair to say, as you did, that it is unixtime that was chosen by all the software. Many programs store datetimes as strings. Usually, they still don't support "23:59:60" anyway, but that doesn't really make them unixtime. Unixtime is a timestamp encoding.)
So, that's basically what I'm talking about: you can just make unixtime an implementation of TAI (as opposed to UTC). You can build a new calendar format for it, introduce a new name (not UTC!) for it and see how well it does when all the world slowly drift from Earth's rotation to keep up with TAI. Maybe it actually is fine, I'm not a judge for it (because it really is complicated and I didn't decide yet if it's a good solution or not). But why the fuck would you destroy UTC for it?! It is a closest usable representation of UT1, which doesn't stop to exist! Leave it be!
I really hope we can get something like TCB standardized for computer use with affine transform to human-usable times.
This recalls perhaps the biggest mistake in the GPS specification, the 1024-week rollover period. A timespan long enough to be impractical to test without expensive simulator hardware, short enough to be virtually guaranteed to cause problems in long-term installations... and long enough for OEMs to ignore with impunity. ("Eh, it's 20 years, by that time I'll be retired/dead/working somewhere else.")
Moral: timescale rollovers need to be designed to happen very frequently -- as in a few days at most -- or not at all. Unfortunately the leap second implementers didn't have that option.
I like to think that applications should be written under the assumption that the computer could be used by time-travellers, with the clock reflecting the respective changes to “local” time. That is, you would have calendar dates and wall-clock times reflecting the time travel, plus an elapsed-time clock reflecting the CPU’s subjective time. Then design your systems around that. As a consequence, they should also be immune to leap seconds and DST switches. But I guess that’s too much to ask. ;)
But how do you know whether the sun is up or down in any given place on Earth right now? You probably don't, if the place is a few thousand miles East or West from where you are. You'd have to look up its time zone. And doing that might not be that much different from looking up at what hour the solar noon is somewhere else.
Oh wait, we’ve reinvented time zones!
Basically, the point of time measured in hours and minutes is to be useful to humans in daily life. And it’s useful to have a common language for things relevant to humans.
other way around. e.g. unix time is determined by the number of seconds (as experienced by some point fixed to Earth, roughly) relative to some reference point. duration is the native format for most time systems, like UTC, because “absolute time” isn’t a thing that can be measured. faking the duration (e.g. adding leap seconds) within a time system is sort of nonsensical: we only do it to make translation across time systems (UTC, UT1, local/human timezones) simple. if that’s the justification for things like leap seconds, then better to keep the time system itself in its most native format (assuming that format is useful locally) and explicitly do those conversions only when translating, i.e. at the network boundary: when communicating with a system that doesn’t share/understand our time system(s).
The international standard for monotonic time is TAI, which never had leap seconds, but which is also used by almost no one
So, to sum it up:
- TAI is a real thing, it has a concrete meaning, and it's "leap infinity".
- UT1 is a real thing, but is unusable in practice, and you could think of it as "leap ms"
- UTC until yesterday was a real thing, meaning time, which has seconds equal to TAI-seconds, but not drifting from UT1 for more than 0.9 s. Since today it's broken and I'm not sure what it even means anymore — I mean, not in practice, but "platonically".
- Nobody just introduced a standard that would mean "time with seconds equal to TAI-seconds, but not drifting from UT1 for more than 59 s" yet. I guess you could be the one to do it, but I'm not sure it would get a wide adoption.
Say I have a timestamp in the future, and I want to add a day to this. Then the first approximation would be to add 246060 seconds. However if there occurs a leap second in that day, the correct thing is to add one more second. But I do not necessarily know today, if there will be a leap second. So I cannot compute the correct timestamp.
So to walk through your requested example…
You store a TAI time stamp of when you originally chose a specific date/time and then you store either a chronological time stamp (the TAI value) or a calendrical timestamp which is a struct/dict/etc storing the desired year month day, time and timezone and notionally the calendar system unless you want to assume the Gregorian calendar and risk confusion with Julian calendar dates which are still in use for astronomical record keeping. With these two values you can calculate what to change in the struct to account for any time change, a day not being fixed as a number of seconds allows accurate calendar calculations. You increase the day value and make sure you don’t have to “carry” a month in the months column.
Yes this is more calculations when modifying a value compared to just adding a bunch of seconds but that’s the issue at the heart of this problem, calendars and chronological elapsed seconds are fundamentally different and we computer programmers tried to take a big shortcut by using a single seconds value for both… and thus… here we are with the present state of affairs.
Wrong info from before edit: Unix time doesn't change either, it's the number of seconds since 00:00:00 UTC on 1 January 1970, though systems may or may not ignore that and set it to match the UTC time.
Also, if the problem were time zones, time zones already support non-whole hour shifts, so why not just apply the leap second into all time zones? The reason is that that isn’t what a leap second is. It’s kind of “how much time has elapsed since 1970 midnight” and that number is corrected for with leap seconds. Time zone offsets don’t help you here.
And timezones one hour wide impose about a +/- 30 minute fixed error (and sometimes larger) on top of that - the difference between local mean time and local civil time.
Quite common in real-time sports betting world.
With busy waiting, you can achieve timings in the sub-microsecond range, depending on how heavy the loop is.
Key words: constant TSC, invariant TSC, TSC clocksource
However they may be more accurate than 1ms. The guy is saying the timeslice given by the OS for a program to run in has at best a 1ms slot because the OS is switching between threads on a 1ms timeslice basis
So unless you're polling, the timing at which you ask the hardware for nanoseconds will jitter with 1ms offsets
There's no reason this wasn't done many years ago except for a blunder on the part of CGPM which they are now working to correct.
I don't think you understand how the tzdata works: the tzdata folks only update the contents after the civil authority for a region changes the law.
So first you have to get all the law makers to update what the legal statues say and then you "just" update the computer systems. The latter is the 'easy' part, it's the former that's the coordination problem.
And as someone who was around for the 2005 DST change, I can say that may also be quite the coordination problem. (Though I think code has gotten much better since then.)
Timezone adjustments do not. They are fundamentally a local matter, and just need to be communicated to the tireless maintainers of tzdata, and can happen incrementally any time an area feels local time is too far off solar time.
The guy is overgeneralizing IMO. You can delve deep within the sub millisecond world even as a regular dude with a regular computer and a regular OS by just doing everything in an interrupt context
I don't know of anything that actually requires UTC to be within 1 second of average rotation-based time; having it within 2 or 3 seconds is extremely unlikely to actually break anything. But we do generally want to have measured time roughly in line with Earth time in the medium to long term.
Here, look. Using the time zone for Norway in this example, with the `date` command on macOS.
First the last second before DST ended in Norway this year.
TZ=Europe/Oslo date -I seconds -jf %s 1667091599
2022-10-30T02:59:59+02:00
TZ=Europe/Oslo date -I seconds -jf %s 1667091600
2022-10-30T02:00:00+01:00
Everyone should follow RFC 3339.
And for a lot of things problems would be solved with +01:00 offset while for others you actually want Europe/Berlin offsets
Sorry not personal but I find myself explaining that each time the subject comes up at work (and generally to the same people... sigh)
The earth rotate around itself in 23 hours and 56 minutes
(/s)
Is it important that midnight is actually midnight? I don't know. I would prefer it to be, but perhaps I can just update my knowledge on when the midnight actually is once or twice a year. Perhaps it isn't a big deal at all. But I wouldn't dare to claim that "surely there can be no problems with it".
And, yes, that kinda means I don't support the leap second removal. It wasn't great, but eventually fixing the software written by incompetent people sounds more like a solution, than breaking the existing solution and making both competent and incompetent people alike eventually come up with a new one (to abolish it as well after 100 more years).
Midnight is almost never at midnight.
Let's talk noon, specifically solar noon, as it is easier to visualize. Solar noon varies throughout the year, and based on the position in the timezone.
Solar noon for two cities in Eastern Time Zone: 11:29:16 - Boston 12:22:36 - Atlanta
Tomorrow, solar noon in Atlanta will be 12:22:50, 14 seconds later than today. No one notices a 14 second shift from one day to the next. As you can see, solar noon is almost never at clock noon, yet no one complains about that. Who would notice a 1 minute shift over 100 years?
The programming problem is made vastly more difficult because the leap seconds are not known in advance. When a new leap second is announced, every dependent system has to be updated.
I'm not sure how this differs much in practice from UNIX time
(Negative leap seconds are similar, and do not affect the monotonic property.)
POSIX/Unix timestamps, however, are non-monotonic. But that's a different timescale.
(i'm guessing that this was purely a joke and no such thing exists)
This is a euphemism. Please don't use it.
Close to the plot of a recent Stephenson sci-fi novel:
I'm sure kibwen had in mind a Hollywood explosion, whereby a detonated object ceases to exist, rather than turning into many smaller objects.
But we're here now and we have to fix this. So anything that moves us away front his problem is helpful.
This decision just dominoed down through time causing enough friction that we computer programmers outweighed the metrologists and they caved and abandoned properly keeping UTC in order to stop causing problems for everyone else due to our continued failure to fix the root cause of these issues.
Positive leap seconds are monotonically increasing in UTC, where you get 23:59:60 between 23:59:59 and 00:00:00, but not in typical implementations of unix time where 23:59:59 repeats, and with milliseconds you go (breifly) 58.999 -> 59.0 -> 59.999 -> 59.0 -> 59.999 -> 0.0
If you're only counting seconds, then both UTC and unixtime are always monotonically increasing.
Every trivial variation is another if/switch statement.
> zero sum game of stock arbitrage.
By your definition insurance is zero sum as well. But people find that generally useful. Taking risk off of peoples hands has value even if a widget doesn’t come out the other end.
But why not just a reasonable product? Yes, what could that be, there cannot be something that is fairly priced and people really want, need, what just helps. Not today anymore!
> By your definition insurance
I know what you try there and on a very abstract level you are maybe slightly right, but PLEASE no, high level gambling (==milliseconds&millions) is not at all comparable to the insurance model in many regards, foremost maybe purpose for the community?
(and its pretty clear that fintech here sure doesn't mean the classical bank and modern "normal" payment system... ).
This is a weasel phrase. Insurance is high level gambling as well. They both use risk models to decide at what price they will sit on the opposite side of a trade for.
Decide where you really draw the line and if it’s time horizons that’s pretty arbitrarily stupid. Insurance uses re-insurance quite quickly to de-risk their own books so pretending trading within a minute vs daily/hourly is pretty silly.
Also, most “fintech” is not the “be the fasted to arb 2 exchanges” variety. It’s usually “be a market maker for products that you can relatively quickly price based on proprietary signals”. If speed is your only advantage, the cat and mouse game will wake you up one day getting beat to the order book on every trade.
> and its pretty clear that fintech here sure doesn't mean the classical bank and modern "normal" payment system...
Not sure where you got that from. All of this is interconnected. The “classical banks” are all participating in deep fast moving bond markets. JPM doesn’t send their orders to some old timey trader with a cigar and a bowler hat via telephone. They use fintech like the rest of the industry.
Yet when I go somewhere with no liquidity and a huge spread like a crypto exchange, a deeply unpopular corner of the stock derivatives market, or a Craigslist used stuff category, the wide spread is just a mild inconvenience at worst. You get to choose between waiting for a better deal and taking a worse deal immediately
A tight spread just means that somebody is getting rich by taking that choice away from me and everyone else on the exchange. It's not the most nefarious thing in the world, but it's not particularly helpful or altruistic either.
Someone who wants to buy or sell goes to a market in order execute at the best price achievable, and they may be under time pressure.
If the spreads are wider at one place than another, participants will gravitate to the place with the narrower spreads. If there is better liquidity at one place than another, activity will move to that place.
The purpose of being at the market is that you want to trade.
These qualities that you dismiss, "a mild inconvenience at worst", are the essence and measure of a market's effectiveness.
"A tight spread just means that somebody is getting rich by taking that choice away from me and everyone else on the exchange."
No, it is the opposite of that. It is when spreads are wide that there is easy opportunity for getting rich. Consider: it is more lucrative to buy from one person at 10 and sell to another at 20 then to buy from one at 15.01 and selling to another at 15.02.
"You get to choose between waiting for a better deal and taking a worse deal immediately"
That is not the choice. On a good market you get both a competitive price, and you get to deal immediately.
An order that you rest on the book is called a limit order. You can do limit orders on any market, even those where market makers operate. Creating a market that offers limit orders is easy. The more challenging problem is to create a market where people can come and place market orders that get filled immediately
Four years ago, I wated to sell stock to close a deal to buy a house. I didn't want to sit around for hours or days or weeks or forever tweaking limit orders, hoping the market would move in my direction and that the house would stay on the market. I went to market to execute, got my money, and put down the deposit.
If a company goes to a market to offset risk, they typically want the convenience of getting the deal done immediately. If they have to wait weeks to close the deal, the risk might already have past by the time they could get the deal done. Liquid markets with tight spreads get rid of the workflow and loss of time inherent to haggling whilst giving you justified confidence that you are getting a competitive price.
Despite the useful service of price discovery (here are so many better ways) it is clear from the EMH that those computers are not doing arbitrage, they are front running trades.
Illegal. Criminal in USA (I think). But makes billions and billions for the already very rich. So that is why there is so much of it
“In this is love, not that we loved God but that he loved us and sent his Son to be the expiation for our sins.” (1 Jn. 4:10)
For example you can forbid futures and derivatives without forbidding good old stock trading.
However, it might be much more interesting, and societally more beneficial, to require that anyone trading in commodities futures must have, at all times, the facility to take delivery of the contracts. The upper limit of exposure for a trading desk would therefore be bound by the capacity of their physical infrastructure.
Otherwise these 2 guys could fill their orders immediately.
10 20 means you can sell for 10 and buy for 20 instead.
Imagine a world with no market makers. There would still be plenty of buyers and sellers of SPY shares at any given time to keep a tight spread and fast execution, but people placing market orders would get slightly worse execution and people who can accept the risk of placing a limit order and waiting two seconds would get slighty better execution. The ONLY real difference is that there wouldn't be some market vampires magically extracting tiny bits of profit all day. Your Facebook shares would still move just fine even if nobody front-runs your order and takes a few cents from you.
I get it, market making is profitable and the victims are distributed widely enough/offset enough by trivial benefits that it's not a particularly bad thing to do. But they aren't making ANY positive contribution to society AT ALL by squatting on the exchange and intercepting all the market orders at a profit.
(Full disclosure: this whole argument obviously goes a different direction when you start talking about derivatives, since market makers are mostly the ones who create and offset the derivatives. I could believe an argument that they're making the world a better place by making it quick and cheap to mitigate financial risk)
You seem fixated on the latter, to the extent that you will define away the quality measures of a market to get there.
The vampire/victim labelling you use is unreasonable. Market makers rest liquidity on the book and then other participants choose to interact with them. Both participants have chosen to enter the deal.
You propose a market without market makers. If you set up such a book, I expect you would find that nobody would want to trade there because they will get better prices and more liquidity elsewhere. If it was a good model, then all the exchanges would be doing it.
You misuse the term front-running here. Front running is when a broker has an order from a customer, and places orders on their own behalf before processing the customer order. In doing so they would put their own interest ahead of the customers. Rules about front running are a form of consumer protection. On-exchange market makers do not have customers, so the concept of front running is not relevant there.