"Noon" is rooted in a physical phenomenon - when the sun is highest in the sky. But "UTC Noon" is arbitrary, because we had to pick a point on the earth.
Leap seconds are trying to ensure that, standing at the point we arbitrarily picked for UTC at noon, the sun will be at its peak.
That doesn't feel like something that NEEDS sub-second precision. I mean - by walking from one side of a time zone to the other, you can have an hour or more of imprecision. https://i.ibb.co/r000S5s/caxxyddlsgp11.jpg
> Is there a single system currently in existence which can handle a leap minute?
Every system can handle a leap-hour, they happen twice a year in many countries, courtesy of DST.
So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km, fixing the error while keeping UTC monotonically increasing 1 second per second.
And to update our clocks, use the one mechanism that we already rely on comfortably - timezones. Add 15 minutes to each timezone, the same way we handle DST now.
>So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km, fixing the error while keeping UTC monotonically increasing 1 second per second.
Shifting the prime meridian 400km seems like it'd have some unintended consequences akin to the Y2K problem. Its physical location is used as a reference point in some coordinate systems, ECEF for example.
You don't need to move the prime meridian, you just need countries to update their individual time zone offsets from UTC, which is already a well-supported path that happens all the time. If we abolish leap seconds, countries would just wait until solar noon drifted ~30 minutes (which would take centuries), then just do a TZ offset update. Nothing could be simpler.
No, they're suggesting a solution akin to Eastern Kazakhstan was on UTC+6:00:00 one day, and on UTC+5:00:00 the next day.
This actually happened last March[0] and I'm not aware of anyone outside Kazakhstan being inconvenienced by it at all. tzdb updates happen several times a year and everything keeps working fine.
No, I'm saying that e.g. Central Europe Time keeps being defined as "UTC+1" for the next few centuries until solar noon has drifted about 30 minutes away from civil noon, then CET's definition changes to be UTC+0 or UTC+0:30. This is a time zone update of the sort which happens constantly (e.g. in 2017, Chile changed its TZ offset, Haiti started using DST and Mongolia stopped using DST. A TZ offset change to account for clock drift would be exactly the same)
To be clear, for decades, we've not sought sub-second precision. We've sought precision of a second. Maybe we should seek more-- the big problem with leap seconds is that they've been rare enough to not be tested completely well, but common enough to provoke problems.
> And to update our clocks, use the one mechanism that we already rely on comfortably - timezones. Add 15 minutes to each timezone, the same way we handle DST now.
Then everything in the world that displays time is going to need a software update when you're going to do this, or it will show time off by 15 minutes.
I do think it could be sane to let UTC's offset to drift up to +3.0 to address this temporary trend of a "fast Earth". Of course, that's going to make leap seconds rare for awhile, and it will come back and bite us when the recently-untested event of a positive leap second happens again.
Yes, stuff should be, but a 15 minute adjustment within a zone suddenly is going to screw a lot of devices. Not everything that consumes UTC is internet-connected.
Heck, every existing radio-derived clock that presents time to users would be obsolete (lots of GPS, WWV/DCF watches, etc).
A lot of them have TZ-related breakage, but they usually let you set a manual hour offset or consume a daylight flag.
I think you are underestimating how long the scales are here. It could take 1000 years to be off by 15 minutes. By this time every electronic device that exists today will be either gone or in a museum.
I know it's a long time. But it's probably more like 200-250 years or so to be off by half of 15 minutes (which presumably is when you'd do a 15 minute step). And it might be a lot less than this.
In any case, I think frequent, well-tested procedures are better than an exceptional procedure on the order of decades or centuries.
We make small semi-regular changes to timezones all the time. DST switches, governments arbitrarily deciding that their country is going yo be in a different timezone (at a 2 day notice), or move the DST switch day by 2 weeks, etc etc. This is a solved problem and it happens all the time. The systems and datastructures that can deal with this (eg tzdata and the process & people behind it) are already in place.
> This is a solved problem and it happens all the time.
UTC changing does not happen all the time: what the 'all the time' thing is a display/UI offeset against UTC. Time itself is not changed in those situations, but would be with a 'UTC jump'.
The closest thing we get to universal time 'changing' are leap years and February 29, and we regularly get stories about people messing that up. And if something as common and regular as that gets fumbled I have little hope for pulling off a one-off jump of UTC.
It is coördinating the universal part that I would imagine to be the difficult part.
Then just keep UTC when it is? (ie allow its prime meridian to shift away from Greenwich) Adjust all the timezones by half an hour in a few millennia. It’s really both fine and up to our grand-grand-grand-grand-etc-children to decide.
This really doesn't solve anything either. Attempting to treat time as something that ticks towards the future at a consistent rate relative to all observers is already broken. The Earths rotation is slowing down over geologic time. Even on short orders things like earthquakes can change rate of rotation of the planet. Start putting stuff on spaceships and different planets and you start seeing how wibbily wobbily time really is.
Just like we have to focus on making application secure, we need to ensure our applications don't shit their pants when applications change time in unexpected ways.
> It’s really both fine and up to our grand-grand-grand-grand-etc-children to decide.
I'd rather build gradual adjustments into our systems so that they have to be resilient to this sort of thing. Sure, leaving it up to our distant descendants is enticing, but then they're going to have a Y2K-sized problem to fix. I'd rather leave a legacy of systems that were designed to be resilient.
It feels like you missed the main point. Time-zone changes are already very easy to handle and are sufficient for dealing with this problem without having to use a leap second or leap minute ever.
> Time-zone changes are already very easy to handle and are sufficient for dealing with this problem without having to use a leap second or leap minute ever.
TZ changes are a display delta against UTC. The closest thing we get to universal time 'changing' are leap years and February 29, and we regularly get stories about people messing that up. If something as common as February 29 is fumbled, what are the odds of pulling a one-off event?
And as someone who was a sysadmin when the US changed its TZ rules many moons ago, the sudden rule change was anything but straight-forward given the fairly static nature that they had been for the long history of software development that had occurred until that point: a lot of software is US-developed, and there was little/zero consideration to updating rules. (Though I think that event caused a lot of developers to be more understanding.)
The point is we don't need to change universal time. Thousands of years from now, when solar time drifts away from UTC enough for a particular country to care, that country can change its time zone. There doesn't need to be any global coordination and the process will be gradual enough that nobody will notice.
The EU already fails to agree on dropping DST (and adjusting time zones in the process), because member states will be affected differently, and neighboring countries that should really be in different time zones benefit from being in the same zone. I doubt they could agree on shifting their time zones, because invariably some countries would get the short stick.
I keep repeating this point but for some reason people keep ignoring it. Countries do not have to agree to change time zone. They can each change it whenever they want.
The point is they will not want to change their time zone to a different one from their neighbors if they are in the same zone, because that has economic downsides. And the neighboring country will not want to change along because winter mornings will be too dark or whatever. It’s exactly the issue that currently prevents dropping DST in the EU, although a majority would prefer not changing clocks twice a year.
In 400 years we can define new 30 minutes shifted timezones and in 400 - 500 years governments can slowly change their official timezones (maybe at summer/winter time they shift 30 minutes instead of 60). It does not feel like a big issue.
I wouldn't even suggest a solution. Let the people thousands of years in the future figure it out. Working out solutions now is like asking people from the time of Jesus what we should do about the clock for a worldwide computerized network.
> Every system can handle a leap-hour, they happen twice a year in many countries, courtesy of DST.
Any DST aware system I've checked handles this as a timezone change rather than changing the underlying time, expressed in UTC. Even for locations where DST's onset removes an hour rather than adding one.
We already have that system, and it's called TAI. You are free to use TAI instead of UTC in your computing projects, and don't have to try to change the definition of UTC.
Which is a very good reason to abolish the leap second in UTC to make it the same as TAI time. We can then make a new standard that includes the leap seconds and add them to that (which computers will only ever deal with when they format datetime).
Leap seconds are absolutely part of the local datetime conversion functionality of time and not part of the counting functionality. Unix time should never have been different from TAI time in the first place but somewhere along the line some idiot made the absolute undeniable blunder of putting the seconds offset of the suns position relative to earth in the counter of seconds rather than putting it in function that formats the local datetime.
Anyway here we are. It’s totally fair that UTC includes leap seconds but unfortunately they passed on UTC as is into the unixtime seconds counter which makes no sense since computers don’t print UTC datetime directly anyway, they have a special date() formatting functions that could easily and problem free add seconds as needed.
So what’s the solution? Well telling everyone to suddenly adopt TAI is difficult. But we could just abolish leap seconds from UTC effectively migrating everyone without them realising it. Now I know that sounds odd. After all this blunder wasn’t done by the UTC creators, it was the Unix guys that fucked up here. UTC is literally meant to track the sun after all. But still it’s the easiest fix and we can always create a new UTC, UTC_leap_seconds, that we can use in our datetime printing functions if we want. Abolishing leap seconds from UTC and thus Unixtime will make the world run more smoothly. It’s also been planned as we speak so you don’t need to do anything but wait! :)
> Which is a very good reason to abolish the leap second in UTC to make it the same as TAI time. We can then make a new standard that includes the leap seconds and add them to that (which computers will only ever deal with when they format datetime).
I think it's weird how people react with such horror to the idea that maybe, just maybe, it wouldn't represent any kind of problem to the people of the 23rd century if 12:00 didn't correspond to the instant the sun was directly overhead, but instead a minute past. Nor would it cause any issue for people thousands of years from now if 12:00 was in the evening or the morning or any other part of the day or night. For those future people it would simply be the way things are, and it would stay that way their whole lives.
Noon already does not correspond to the sun overhead. Timezones, and IIRC the time of year and inclination relative to the equator matter too.
However, irrespectively, it's basically never solar noon at noon if someone is using time zones rather than local solar time, which of course would be a custom timezone for that exact location.
The time of year does matter a bit, but the effect is smaller than the effect of timezones. Their equation of time article includes a nice graph of the variations in time of solar noon at Greenwich. https://www.timeanddate.com/astronomy/equation-of-time.html
And a related thing, the analemma - the sun's position at the same place on earth at solar noon over the course of a year doesn't resemble an arc, it's a figure-8: https://en.wikipedia.org/wiki/Analemma
Many parts of the world move forwards and back a full _hour_ every year. We complain about it but it’s mostly ignored. A gradual drift of a couple of minutes is fine.
I work in Arizona, and some of our software calls APIs on a server hosted in California. The California server expects timestamps in requests to be in Pacific time, with no timezone in the timestamp, and expects them to conform to daylight savings rules.
This gets very hard to reason about because Arizona doesn't _do_ daylight savings. Like, what happens when we request 24 hours of data from them, on the day daylight savings time flips over? Do we want midnight-to-midnight data, or do we actually want 24 hours of data, which might wind up timestamped differently since there's a duplicate 2AM one day and a missing 2AM another day.
A few years ago we had a contractor write some extremely messy code to handle cases like that, and soon it's going to be my job to try and refactor it into something readable.
It's surprising how many vendors of security product refuse to use UTC for timestamps and insist on using the local time of their bay area data center. The number of edge cases that arise from DST issues that are significantly reduced, if not completely eliminated, by using UTC should be reason enough for security product vendors to see it as a core best practice.
I'm amazed to hear anyone doesn't use UTC, I'm not a professional developer and I remember learning, just while teaching myself the basics of PHP & MySQL as a teenager, that it's best to have databases store either UTC or a Unix timestamp (which afaik is essentially the same as using UTC except that it's less easy for most people to read at a glance) and to do the conversion to any local time zone wherever users interact with it.
I have a rule of thumb that software works progressively worse the further you are away from the Bay Area - both geographically and culturally. For example, we use roundabouts (traffic circles) everywhere here in Australia and google maps still gives pretty terrible directions when driving on them. I was shocked the first time I drove on the 101 just how good the spoken directions are - but it makes sense given the actual Google maps engineers drive that road. If the directions were bad there, they would get fixed.
I shudder to think how many bugs must show up for people who use right-to-left languages or use non-ascii charsets - especially before Unicode & emoji were popular. I’m ashamed to admit I don’t even know how to test if my software works properly in languages like Arabic.
Of course software made in the Bay Area assumes the whole planet uses pacific time. I’m sorry to throw shade, but that’s entirely in character for the area.
> I have a rule of thumb that software works progressively worse the further you are away from the Bay Area - both geographically and culturally.
It's not just software. EVs struggle with cold and hot climates. They'll get better, of course. But with the engineers living in mostly temperate climates, conditions outside the development environment get less upfront attention.
The two worst offenders I can think of with regards to using local time were Rackspace, and Southwest Airlines.
Not in the Bay Area, but every other west-coast company I've been involved with is pretty militant about using UTC, typically due battle wounds from communication challenges or time-related bugs.
I would be very curious to hear which other major companies are deploying systems on local time in 2024.
> either UTC or a Unix timestamp (which afaik is essentially the same as using UTC except that it's less easy for most people to read at a glance)
UTC has leap seconds, unix timestamp doesn't. It's defined to have 86400 seconds per day, so there's no place to put a leap second. Instead, it either duplicates a timestamp or does "leap smearing" - slightly changing the duration of a second around where the leap second is.
The most amazing of these exceptions is Microsoft Windows 11, which still uses local time on the hardware clock, a legacy of decisions made over 40 years ago. Raymond Chen defended this practice (20 years ago) https://devblogs.microsoft.com/oldnewthing/20040902-00/?p=37... . It's possible to make it use UTC, but it requires registry hacking.
Why would anyone choose to use local time for anything other than display? That just seems way harder even if you don't have customers from other timezones.
> Why would anyone choose to use local time for anything other than display?
You need to store it for certain applications, e.g. timetabling. if school starts at 9am, it starts at 9am local time, and if local time changes (DST, or more rarely a change in the time zone rules) then school start time runs with it. Or similarly, if a commuter train timetable has it stopping at a certain station at 7.05am, that’ll be local time in the local time zone.
I arrived 1 hour late to an online meeting once in which I was scheduled to give a talk. The root cause was this: I (in Australia) was subscribed to the event calendar. The event was actually a reoccurring event at the same time every month in UTC time. But day or so before the event happened, daylight savings changed in LA - which for some reason was the time zone the calendar was set to. As a result, the meeting in my local Australian time drifted by an hour. Unfortunately, only some people used the online calendar. So many people (including the organisers) showed up on time.
Are you saying the calendar was set the "DT" (daylight savings time) and not "ST" (standard time) so when it actually flipped the calendar adjusted 1 hour in the wrong direction? heh, yeah that would be very frustrating, glad it wasn't like a final exam (for students) or an oral presentation in front of a client (for consultants/professionals).
edit: not trivializing missing the talk, i would be pissed.
DST is in opposite halves of the year in different hemispheres, and also the transition dates will be different in different DST-using countries even in the same hemisphere.
So the timezone difference between US and Australia (or at least their DST using parts, since in both countries some states don’t observe DST) is 2 hours more in one half of the year than the other. And it changes four times. In January, Australia has DST and US doesn’t. Then in March US starts DST and moves one hour away. In April, Australia ends DST and moves another hour away (in the opposite direction). In October, Australia starts DST and moves an hour closer to US. In November, US ends DST and moves another hour closer to Australia.
Time zones are totally fine. They're unreasonably hard to do math with (ahead/behind +/- just refuses to stick in my brain), but they massively simplify life most of time they come up.
The thing that's a curse on humanity is daylight saving time.
Yeah, timezone abbreviations are problematic because how am I suppose to remember what time zone offset “EST” is? Here in Australia, we have “EST” too, but ours is UTC+10 not UTC-I forget
You can look it up. Or ask Google “time now in PST”. (“Pacific standard time” - which means San Francisco, obviously. It’s not like other people live near the Pacific Ocean).
But there’s PT (pacific time), as well as PST and PDT (pacific standard and daylight savings time) if you need to be specific with whether or not daylight savings is happening.
EST, according to Google, is the east coast of America when daylight savings is not happening. For Sydney and Melbourne, you want AEST / AEDT / AET depending on if you want to specify Australian east coast standard, daylight savings or current time (which changes depending on the date).
It’s all hilariously exhausting to keep track of. Simple enough you think you can remember it, but complex enough you will miss your meeting even though you checked twice because the calendar was set to the wrong timezone and it didn’t matter until today. The relative time between Australia and California changes 4 times a year by 1 hour, depending on the local daylight savings time in both countries. I hate it.
Some computer systems (probably designed by Americans) want timezones to have abbreviations but insist they can only have three letters, so in those systems the Australian timezones have three letters. I definitely remember seeing EST meaning UTC+10 on Unix systems before
I try to refer to local time in an area I'm not in as <location>-time rather than the timezone's canonical name to avoid this kind of confusion. Then use a world clock to tell when that is. e.g. "That livestream should start at 4:30pm Vancouver time."
> they massively simplify life most of time they come up.
I have coworkers and friends in different timezones, and timezones do literally nothing but complicate coordination. Even if it's a small friction, they are 100% friction.
As far as I can tell, the main benefit of timezones is that it allows people within the same timezone to converse as if timezones don't exist. Which would also be the case if timezones didn't exist.
I know a bit about the computer system at our children’s school. I only have access to the parent portal, but that’s enough to give me some idea how it actually handles things. Plus I used to work for a university, and I got a good look at the internals of its system - and timetabling isn’t fundamentally different between primary/secondary and tertiary, just it gets more complicated as you move up.
So, to answer what I think you are saying - normally you divide the day into chunks (“periods”). At our children’s school, it is primary, there are only two notional periods a day (morning and afternoon), when our son goes to secondary school next year (which appears to use the same software) there will be several periods a day, one per a subject.
Anyway, in the system, a period is a class, not just in the academic sense, but also in the OO sense, and as such it has instances - “morning period” starts at 8.35 am local time any day the school is open. So that start time would be stored without a date, just a time plus time zone. But then, there is an instance of “morning period” every one of those days, which starts at a particular instant in time - today it starts at 2024-07-04T08:35+10:00. And yes, you could store that just in UTC, and convert to the school’s local time on display.
I suppose there are three main data types you really need: (1) date without time (2) local time in specific timezone (3) UTC instant
For (1), whether you need the timezone or not depends on the use case. For stuff like dates of births, you generally won’t know and don’t really need to know the timezone in which they were born. But, for other applications, it becomes important, since Wednesday afternoon in the Americas is Thursday morning in Oceania and eastern Asia, so whether it is Wednesday or Thursday depends on your timezone. People expect days to start and end at local midnight, not UTC midnight - which for me is 10 or 11 o’clock in the morning.
For hire dates, many jurisdictions have employment laws that have different rules depending on how long you’ve worked there. So you need to know how many days since hire to know what legal regulations apply to the employee. And obviously that is meant to be calculated in local time, if you do it in UTC or HQ timezone it could be a day out, which might cause legal issues. (e.g. in some jurisdictions it is easier to fire an employee in the first six months, you wait until the last day to terminate them, except because you got the day off by one, that was yesterday, now you have terminated them illegally)
If your application's use is local enough that more than one timezone isn't a concern, and doesn't much (or at all) care for things that span overnight, so you don't have to worry about adding/dropping an hour to the length of things when some sort of DST event happens, just using local time across the board is simply easier.
Of course as soon as one of those assumptions is not 100% true, using UTC internally and local time for display is usually by far the better option (though there can still be difficulties there – time is never as easy as you'd think it should be).
The trouble comes when people use to working local only (timezone wise) slap together a PoC of something that might need timezone awareness, and don't fix the deficiency at any point as they progress through PoC->prototype->alpha->beta->v1. The longer you leave the change the harder it is to do, and it not being easy is why once something nominally reaches V1 (or often at first alpha release) such a fix is seldom ever made.
Timezone awareness has improved massively in recent years though. I think some cloud providers have accidentally helped there by defaulting to UTC (for instance all AzureSQL DBs default to UTC for everything, as do VMs and other things in Azure). Though here in the UK minor issues due to bad assumptions are still common when we transition back or forth between GMT and BST.
Yeah, and even if those assumptions are perfectly fine today, they are unlikely stay that way. When they do, going back and fixing everything else is a massive pain. Even ensuring everything is in localtime can be a pain; someone decides to add a database you didn't have before and didn't pay enough attention to its configuration? Too many landmines.
The way to avoid this pain is to just use UTC on day one, regardless of requirements. Hard and fast rule that everything needs to be UTC. Need to display it? Converting to local time is trivial.
Same thing for text. Use Unicode unless otherwise specified.
> just use UTC on day one, regardless of requirements
That can cause extra concerns for always-in-one-timezone systems where you might care where midnight falls (“did this event happen today or yesterday?” is a question that needs extra steps to answer, for instance). Nothing complicated, but extra work you might want to skip at the quick PoC stage.
But yes, beyond PoC work and all but the simplest other work, I'd agree with UTC all the way from the ground up.
Yup. The only exception I could think of are prearranged local times, e.g. the meeting will be on -future day- at -local time-. In that case, if, say, the time zone changes, the meeting would still be at the same local time and not move.
Because DST might be a thing right now in that zone, but may no longer be next year, in which case the historical DST is needed to refer to times in the past.
Same for dates a bit further back when countries changed calendars and some days are missing.
So, we basically need a mapping of UTC -> local time as a function of time, and store this forever.
(For durations, we might need to have a mapping from TAI to UTC as a function of time, because a leap second messes with duration length. Smeared leap seconds are even worse in that regard)
About half of the world would 15+ minutes away from sun directly overhead at noon if hour-aligned time zones worked correctly, leapseconds are "solving" a "problem" at a level of precision wildly at odds with actual usage.
Even besides daylight savings time, timezones exist. England and Spain are on a vertical axis, yet the timezone differs by 1 hour. Cross the border from spain to portugal and time jumps a full hour, so there are people living 100 Meters apart with 1 hour time difference.
I've heard that this is why Spanish people go to bed so late. They are going to bed at the same solar time, it just seems later because of the time zone they are in.
> The Spanish also go to sleep later than their European neighbours. According to Eurostat, Spaniards go to bed, on average, at midnight, compared to Germans at 10pm, the French at 10.30pm and Italians at 11pm.
It's not that many parts of the world. DST is a very western "problem" that most of South and Central America, Africa and Asia simply don't have to deal with.
Funny that you only consider North America as 'western'.
Brazil, the largest country in South America, had DST until very recently (2019). A large chunk of South America observed DST at some point. Some stopped in the 90s, others stopped much more recently.
Its not quite the same problem. Timezones are a transformation applied on top of UTC. If you are writing code, you are transforming the always increasing UTC to a more or less arbitrary dates and times.
Moving backwards means you (your code) experiences the same time twice.
It is not exactly same, but it can be framed as the same problem by requiring every nation to change their own time zone once in a while. As long as the "once in a while" is not frequent (unlikely to happen before 2500, and should happen less than once per century for next 10K years), this should be okay.
I'm always open to change my mind, but I struggle to see the relevance of that in this context.
Are there timezone areas in the world which change their UTC differential fluidly throughout the year and by the yard to pin midday to the highest position of the sun?
I'll definitely say that that'd not only surprise me but blow my mind if true!
It makes a lot of sense to not care about a slight amount of drift. But that already exists: that's what TAI is. Why make UTC into another TAI just slightly offset? Why not just switch to TAI? Or, if the 37 second difference between UTC and TAI is the problem they can make a new TAI-minus-37.
What makes no sense is taking something useful, UTC, and redefining it out of existence. Then what time do you use if you really do care about drift? Do we invent a new UTC?
> Then what time do you use if you really do care about drift?
Nobody uses UTC because they want to know where the Sun is to the nearest second. People who actually need to care about variations in the Earth's rotation speed (e.g. astronomers) already need far fancier stuff than just UTC. People use UTC because someone else made a mistake and decided they should use UTC, like a government standard, or an operating system vendor, or whatever. Unfortunately the best way to correct all those millions of mistakes is to redefine UTC rather than convince everyone in the world to simultaneously switch to TAI.
> taking something useful, UTC, and redefining it out of existence
I question that UTC is useful. What utility does it have over TAI, outside of interoperability with other people who are using UTC? Again, anyone who actually needs to care about Earth rotation speed changes already needs to use something better than plain UTC, and my argument in my original comment is that drift that is small on a scale of a human lifetime is not an actual problem for anyone alive today or in the future.
Getting the world to switch timescales is orders of magnitude more difficult that redefining currently used timescale. The latter can be done in the BIPM backrooms by small committee, the former needs action and agreement from pretty much everyone.
Also, very few people today have the sun directly over their head at noon. If you don't live at the prime meridian, it is an abstract concept. And even if you do, there may be DST. In some countries, you can be hours off.
Few people actually care about the precise earth rotation, and there are time bases for these people that are better than UTC anyways. Sunrise and sunset are important, but the middle of the day, not so much.
Riffing on “if it’s painful, do it more often”, I wonder if mandatory leap seconds every year, but trueing up the delta from N years ago, would be a good compromise? Regularity makes it easier to plan, and 6 months’ notice is not really enough for many OS distribution paths (eg IoT, embedded).
Since the list of delta updates is queued, you could bake N years of updates into your system if it’s a fire-and-forget OS. A number in between 5 and 10 seems reasonable to me, but seeing as we are discussing living with 50 years of drift it could be higher. And sure, for this to work, allow non-integer deltas again; or just have a rule that you round the applied adjustment down.
Seems no harder to bake in the last 50 years of leap seconds as to include to Olson TZ database in your distro.
If you go with that, just move it in the correct direction every year, regardless if you make the absolute delta bigger (you'll fix it in a year by going backwards).
If this is not enough to ping-pong around the correct result, because you're drifting too fast, just increase the rate of changes, now that the system is well oiled.
That said, we should not have leap seconds, just timezones around TAI. If UTC wants to be a timezone that changes every six months with a second offset, so be it. Bureaucratic systems are already in place to solve that.
That's actually a good idea in the short term (i.e. less than one century). The length of the day (LOD) is thought to be linearly increasing in the long term though, so ΔT, the cumulative difference between past SI days and actual LOD, should be quadratically increasing and a delayed leap second adjustment would be too slow to catch up at some point in the future.
Yet another possibility is to put any possible kind of leap second at the beginning of the year. The only requirement set by past CGPMs is that dUTC = UT1 - UTC should be in [-0.9, +0.9] seconds, so we can always put a positive leap second when dUTC is in [-0.9, -0.1]s and a negative leap second when dUTC is in [+0.1, +0.9]s, dramatically increasing the number of leap seconds without violating the dUTC requirement. If the dUTC requirement is a bit more relaxed (say, [-2, +2] seconds) then we can even mandate leap second every year!
But well no, I'm strongly against the current form of leap seconds because it is already problematic in the short term and will be yet useless in the long term. Recall that ΔT is expected to be quadratically increasing in the long term; this means that the effectiveness of leap seconds is limited to the point when any small fixed number of leap seconds per year (12 in the current system, but anything larger than 1 will cause a problem) is no longer sufficient, and that point is not far from the point where the magnitude of ΔT is significantly large and leap seconds are absolutely required. As DST demonstrates, the world is probably fine with ~2,000 seconds of ΔT, which wouldn't happen before 2500, but at that point we would already start using double leap seconds per year at average. We would probably abolish leap seconds for that reason alone.
I have never understood why POSIX and NTP timescales work the way they do. They are positively bonkers when it comes to leap seconds. Time isn't even monotonic during the transition, because the epoch itself is redefined.
Contrast this with the GPS or PTP timescales, which simply count seconds since a well-defined epoch. Formatting the date and time for humans to read is a sensibly separate process.
But then GPS went off the rails and used a 10-bit number for count weeks, resulting in the 19-year week number roll-over (WNRO) problem. A few bits more would have solved a lot of problems..
Given that the first GPS satellites were launched in 1978, saving a few bits was standard practice at the time -- bits were expensive. Code of the time also often had two-digit years (the infamous Y2K problem).
It's 1500. The full data set is 37500 but you get there by spreading the larger message across several subframes. The full data set includes ephemeris data for all other satellites. It's precisely as long as it needs to be. This also means there is a built in fixed maximum number of satellites in constellation.
The time code gets 300 bits. It lasts 6 seconds and it's repeated every 30 seconds. Critically, it will always occur precisely on the top (:00 seconds) of the minute, or the bottom (:30 seconds) of the minute.
Interestingly, most of the time code is used for /correction/ parameters, as precise values for these are required to accurately calculate time. Satellites themselves drift in performance as they age so these parameters are not static for the lifetime of the deployment.
And, yes, I understand that time message gets sent at a much higher rate, hence the “it’s not that simple” part.
But I still have a hard time to believe that it would have been impossible to find 2 or 3 bits in the overall message to include the MSBs for the weeks. GPS units with built-in support for WNRO (due to permanent storage) would be able to ignore it, other units would be able to correct the epoch after 12 minutes (or a multiple in case of data corruption.)
It would have been possible but it would have required a trade off against the other data in the message; however, the goal of GPS is to provide accurate position data, not to provide convenient "calendar time" to individuals. Which is why they spent so lavishly on high precision correction parameters and so sparsely on low precision time of calendar parameters.
From the start, GPS has been used for accurate time keeping as well. And for later versions of the GPS protocol the week number was increased to 13 bits.
I don't even see the need for leap seconds at all (in either direction). Why should anyone care? All times are relative to some arbitrary fixed point in time anyway, so why are we so hung up on maintaining the status quo?
Aside from the fact that just by ignoring the problem it'll probably go away - we've just had a period of adding a load of leap seconds to roughly compensating for the Earth rotating "too slowly" overall, which for a system that's inherently irregular and actually speeds up and slows down all the time, and just happens to have been "too slowly" ON AVERAGE. It now seems hat the rotation speed, on average, is "too fast" and now we need to undo some of that adjustment. If we'd just left it alone, it'd have been fine.
And for all the hassle these leap seconds cause, what exactly has been the benefit? Since 1972, we've had 27 seconds added. 27 WHOLE SECONDS. That would have made absolutely no difference to anybody's life if the sunrise and sunset was 27 seconds later.
Just think, in 100 years, when your great grandchildren are enjoying their life, we might be a whole minute wrong. And if you went the other direction, back as far as all of recorded human history, and we might be out by an hour. Many of us are routinely forced to have our clocks out by an hour for "daylight savings time" every year anyway.
For the very few cases where it might be useful to know the ACTUAL difference between the rotation and alignment of an abritrary fixed point on earth and an arbitrary fixed point on the sub, then THEY can use they own clock for that specialised purpose. And maintain a fixed adjustment to the atomic clock based time that everyone else uses, and they don't even have to round to a whole second for that - they can say NASA time is TAI+1.234s for instance and the only people who need know or care is NASA themselves.
A significant number of systems related to Earth’s rotation (like navigational systems) rely on the difference between UT1 and broadcast UTC to be less than 1 second. If UTC were to change to a constant offset to UT1, those systems would need to be provisioned in an alternative manner to receive a time signal with the same guarantee. Basically, we would still need what is now broadcast as UTC, just under a different name. And if we have that, we might just as well keep civil time synchronized to it.
> Since 1972, we've had 27 seconds added. 27 WHOLE SECONDS. That would have made absolutely no difference to anybody's life if the sunrise and sunset was 27 seconds later.
The delta increases quadratically though due to Earth’s rotation slowing down in the long term, so the problem will only get more severe.
> A significant number of systems related to Earth’s rotation (like navigational systems) rely on the difference between UT1 and broadcast UTC to be less than 1 second.
For most civil purposes, it really doesn't matter but we're techies and it's in our nature to obsess over details like this, often to the determent of ourselves and the systems we're trying to maintain. It appears many of those with the most influence over setting the example for such things in the civil realm have indeed discovered the leap second is far more trouble than it is worth and now it is falling out of favor. For astronomical, aeronautical and other scientific purposes, they'll continue to deal with the hassles, but for the rest of us, it appears the era of leap seconds is slowly drawing to a close.
Leap seconds are both unnecessary and useless at solving the problem they are intended to solve.
If you care about the position of the sun to second precision, then time alone tells you nothing - you need location too. Ironically, most people get their location these days using GPS which is based on TAI, not UTC with leap seconds.
If you don’t care about the position of the sun to second precision then leap seconds are a nuisance.
There’s zero reason to have leap seconds in the definition of time. It should be a database, like tz, that software that wants Earth rotation updates for calculation of sun position can download and incorporate into its calculations for increased accuracy.
The fundamental problem with leap seconds is that you can’t predict what the leap second delta between UTC (legal time) and TAI (absolute time) will be in the future. That’s unacceptable, I should be able to know how many seconds there are between 1 July 2024 and 1 July 2026 without needing to wait for a Time Lord to determine it.
> If you care about the position of the sun to second precision, then time alone tells you nothing - you need location too
Unless you are using time and (celestial) observations to determine your location. It's not coincidence that US Naval Observatory (and its peers) is one of the key origins of UTC.
> but we're techies and it's in our nature to obsess over details like this
Speak for yourself! Part of good engineering is knowing when over-engineered perfection is useless. The inventors of UTC/leap seconds did not, and made a serious mistake the rest of us have had to live with.
> You've reached a situation where campaigning for the whole world to change the way it measures time is simpler than fixing your code?
It isn't just a code problem. Since leap seconds aren't predictable, you have to somehow distribute information about new leap seconds to everything, which is especially difficult for devices that aren't connected to the Internet.
And as the article mentioned, there are multiple ways to deal with leap seconds, and there are tradeoffs involved in choosing which one, and depending on the circumstance different ways. And since different methods work best in different situations, that can result in inconsistencies between different systems.
I gotta say I like this QNTM cat. Wrote Hatetris, "There Is No Antimemetics Division," and Absurdle. A fun explorer of adversarial computing environments. Pretty interesting
Holy shit, this is a world collision I wasn’t ever expecting to see. Thank you for pointing this out, “There Is No Antimemetics Division” is possibly my single favorite piece of fiction I’ve ever read, and I would’ve completely missed this connection otherwise.
qntm, I know you're reading this. As someone working on software that works on ships (aka, software that needs to change timezones and locations often and still maintain contiguous millisecond accuracy of all shipboard equipment events), this article has caused me significant psychological damage.
> still maintain contiguous millisecond accuracy of all shipboard equipment events
can you elaborate on the purpose of this? is it for legal requirements? some kind of "black box" recorder? why does timezone matter for such low-level event data?
Naval boats cost a fortune. The telemetry from the onboard engines/machines/computers needs to be in sync, and they don't always have compatible timekeeping systems, so sometimes it needs to be translated into a common format and recorded in our db's.
If something goes wrong, a lot of parties both internal and external are interested in reviewing the (extremely detailed) logs for the purposes of insurance, or court-martial, or whatever.
Maybe there should be an analog of the Kardashev scale for civilizations capable of adjusting the rotation speed of their planet in order to make timekeeping easier.
I feel like we'll get a (less physically _real_, but much more impactful) run of this "make it to the next day unscathed" adventure in 2038. Only 14 short years...
Does anyone have an actual example where leap seconds are a problem? Specifically one that can't be solved simply by using Atomic Time? Maybe then we can figure out what the problem we're trying to solve is.
Few people or systems even interact with a clock that is precise enough to detect the difference, and instead rely on clocks that are 100's or even 1000's of times less accurate than what would be required to even detect a leap second. And these clocks undergo thousands of corrections between leap seconds without a complaint.
We add an entire day to the calendar about every 4 years. It's not a problem because everyone is aware of it. So I think the only real thing that needs to change about leap seconds is awareness of them.
Leap seconds are needed in civil time because people's schedules are still dominated by the Sun. Not to the second, maybe not even to the hour. But the leap second was chosen because it's large enough to be infrequent, and tiny enough that only a tiny fraction of systems will notice.
> Does anyone have an actual example where leap seconds are a problem? Specifically one that can't be solved simply by using Atomic Time? Maybe then we can figure out what the problem we're trying to solve is.
Any time that is supposed to represent both a wall-clock time has to deal with it.
There is currently no known answer to the question "What is the interval between the unix time stamps @1720026000 and @182002600" However, there is a well defined answer to "What is the UTC time for @182002600" and thus also "what is the local time in a timezone with UTC offset X for @182002600"
If we were to redefine Unix time to use Atomic Time, then we could answer the first question but not the second.
> We add an entire day to the calendar about every 4 years. It's not a problem because everyone is aware of it. So I think the only real thing that needs to change about leap seconds is awareness of them.
It's not just "about every 4 years" it's precisely "every 4 years, except for centuries, except for quad-centuries." If you give me any year, I can tell you if it will be a leap year. I can program a non-internet connected device and it will get leap years right indefinitely. Leap seconds are not predictable, but rather determined empirically and announced about 6 months ahead of time. Any device that wants to properly account for them needs to be updated at least every 6 months to be correct.
Specifically when is not knowing UTC will skip a second six months later a problem for you? As I said, you don't know the interval between any two seconds on your clock, a sync or frequency change can happen at any time. And if you really needed to know the interval at those points, Atomic Time can serve your purpose.
Leap seconds are a problem because I have to deal with existing systems that use leap seconds and those that do not. Getting those systems in sync can be pain sometimes because of conversion from one format to another. Is it insurmountable? No. Is it annoying? Yes. Does it occasionally cause bugs that waste time and resources? Absolutely.
I'd love to snap my fingers and make everyone use TAI, but unfortunately I'm stuck with UTC, GPS and TAI depending on sources.
Time aligning GPS data with other sensors/systems that record in UTC. I'm combining data from multiple different sources together that I do not control. The duration of the data is long enough that an occasional leap second slips in and offsets things.
> Leap seconds are needed in civil time because people's schedules are still dominated by the Sun. Not to the second, maybe not even to the hour.
Sometimes multiple hours off. China has a single time zone.
As far as I can tell, people care very little about the clocks being in sync with the sun. We've effectively run massive experiments demonstrating this.
What experiments are those? I don't doubt if you lock someone in a room they'll lose sync with the sun, but people in society do rely on it. The fact that we use DST in the face of very vocal opposition shows a lot of people do care about it.
The existence of China as an outlier isn't much evidence. The most people on one side do not keep the same schedule as those on the other. If daylight really weren't an issue, there would be only one timezone for the entire Earth. So you can't point to one while ignoring the reason all of the others exist.
Yes if you use atomic time you won’t encounter these issues.
Unixtime made a blunder of incorporating the leap seconds all those years ago so it’s not atomic hence the issue.
Now you might think it’s crazy that Unix time incorporated non-atomic leap seconds when it doesn’t incorporate any other part of the local sun relative position in its counter and you’d be 100% right in that. Leap seconds absolutely belong in the local time printing functions and nowhere else. But the blunder was made and now computers by default don’t have atomic time and here we are.
Or we could adopt the "smearing" technique in either direction and we could do it hourly or daily or weekly or monthly or half-yearly or whatever interval as agreed.
Maybe we should do it every 6 months no matter what. That way, everyone would know that on June 30 and December 31, there would be smeared seconds.
That makes the "do it rarely and people will screw it up" problem go away.
If I am asking for how many seconds since 1970, I'm literally asking for that, as if someone stood with a stopwatch (not a cellphone clock!)
How you want to display that in various timezones i do not care
You speak of time as if it's some directly measurable quantity. Instead, all we have are periodic quantities of various (messy) physical processes or sampling methods thereof relative to certain underlying models:
- _TAI_: Sampled average of ticks in the (very noninertial) frame of the surface an implicitly-defined idealized rigid Earth. Each tick is further a sampled approximation of our definition of a second, which invokes idealizations at absolute zero.
- _UT1_: Mostly the same frame as TAI. Each tick is considered a sample, trying to measure the "true rotation" of some idealized rigid Earth, module any geophysics. Note, the definition invokes quite sophisticated models of celestial mechanics, and explicitly ignores certain kinds of "high frequency perturbations".
- _UTC_: Based on UT1, but take into account some basic, empirically-measured geophysical processes.
Depending on the particular physical processes, models, and sampling methods you choose, the quantity you get for "seconds since 1970" will be different, and there will be (complicated) relationships for how each of those processes transform tick counts between each other. In some cases, the transformations will be a priori impossible, only permitting approximations under simplifying assumptions.
IMO, the remarkable thing is that the various ticks all line up as well as they do, which is why we can mostly get away with treating all these as a single unified Ticking Time concept. On the other hand, I also think the various standards do a reasonable job delineating messy reality into potentially useful tick-producing processes and the systems needed to make those practically useful.
As a software engineer, the lesson for me is that I can't always ask "what time is it?", "how long has it been?", or "which came first?" Instead, we I may need to shift focus onto different invariants in the problem I'm trying to solve.
Really? TAI cannot locate historical dates indefinitely. TAI doesn't even make sense on timescales that exceed Earth's lifetime. It doesn't encode enough information to answer questions about elapsed time of even ideal clocks at real, physical locations to arbitrary precision. Fast enough operations on a distributed database can exceed the precision limits of TAI's definition, making it impossible to canonically order events.
> Fast enough operations on a distributed database can exceed the precision limits of TAI's definition, making it impossible to canonically order events.
The TAI would be a sincronization target, just like UTC. Any device can have its own high precision clock and periodically sinchronize with other clocks (just like NTP does) which to my knowledge is how most distributed systems work
> TAI doesn't even make sense on timescales that exceed Earth's lifetime
I disagree, 10^100 seconds in the future is perfectly valid time in any time system
> It doesn't encode enough information to answer questions about elapsed time of even ideal clocks at real, physical locations to arbitrary precision.
Those clocks would use the TAI to avoid drifting from each other.
> They have chosen their particular physical process: "as if someone stood with a stopwatch"
It's not well-enough defined for all purposes.
Where is that person standing? Earth's surface is shifting and moving all over the place willy-nilly, so how do you define that particular location in the first place? Over what timescales is that definition valid? What physical process do you mean by stopwatch? What particular synchronization protocols do you define? What physical models do your definitions invoke?
Answers to these kind of questions will generally generate mutually-disagreeing time standards. I mean, with suitable transformation rules, they'll often agree up to some precision limit, but if you need anything beyond that, you've now gotta choose the one(s) that best correlate with the natural ticks in your problem domain.
Also, any standard like "someone standing with a stopwatch" is forced to just a fiat declare the stopwatch as the Definition of Time, a la the platinum sphere kilogram. We all know how great that was. Do you now want a team of canonical stopwatches and some aggregation process? How do you deal with measurable drift between the tick rates?
UTC doesn't stop us from having that, UTC seconds tick at SI rate. The thing that makes UTC special is that minutes might have 59-61 seconds each. But if you have stopwatch just counting seconds then leap seconds do not make any difference at all, and UTC and TAI are effectively the same.
Because POSIX committee thought it would make things easier for userland. It didn't; it did make things harder, much harder, for userland and everything else.
Why don't you care about that stopwatch's drift over the past 50 years, the tempreture related variation, the errors induced by motion, air pressure and humidity?
Would you prefer a count that's averaged over many from the same manufacturer, or from many over many manufacturers?
Fun reference, although in that spirit it appears that Null Island at mean sea level for that point might be as much as 22m vertical separation from true 1G Geoid.
Not at all what was asked for; not available as a handheld stopwatch someone could stand with in 1970 ... and I'm doubtful there's such a thing available today.
Works if you don't mind a lab bench full of equipment, but doesn't appear to match the specification of the request.
You're conflating the term "stopwatch" with an all mechanical device. That wasn't even true at the time period specified-- the quartz movement had been created in the 1950s and the first quartz pocket watch had been introduced in the mid 1960s.
The issues you bring up are only relevant to a particular set of devices that can be used as timepieces that measure the amount of time that elapses between its activation and deactivation-- and are are all stopwatches.
You can wrap libtai in almost any language, and that's been done for the bigger ones. Which language are you using, and why is the conclusion not that the language is deficient?
Maybe that's a fun new OS feature. If somebody wants to try it, more power to them.
Answering your question more directly though, why would you want it in an OS? The OS primarily exists to mediate shared resources, and to a slightly lesser degree to sensibly wrap shared code everyone is definitely using (e.g., chrome and hacker news don't have to care about my LCD driver).
What exactly do you gain by baking TAI into the OS? You lose in update availability, OS install size, application-specific customizability, runtime performance of TAI function calls, .... You'd want to gain something for those costs.
> Why would I use a library for a timezone?
Most people do? Even libc localization isn't a part of the OS (and is fraught with issues; never use libc localization), and that's the most primitive timezone library most people use. Everything else is baked into their language runtime or a third-party like nodatime. TAI isn't special in that regard.
the TAI stopwatch, the earth surface is relativistally uniform enough that averaging good clocks gives a good enough clock for almost any practical purpose.
Negative leap seconds will mean that there will be UNIX timestamp value that is invalid. What should systems do when they encounter such value? Generally UNIX time -> UTC conversion is considered to be infallible, negative leap changes that.
Normally, nothing. The invalid UNIX timestamp can still be converted to a (also invalid) UTC timestamp, without needing to know whether or not it is valid. However, when you want to convert to a SI timestamp (e.g. in order to add or subtract a number of SI seconds), then you do have to consider it; in this case it might be an error.
Similar things apply with a positive leap second, although in that case the result is not an error. However, for positive leap seconds, when you are converting a UTC time in parts, into the UNIX timestamp, there is an additional time 23:59:60 for some dates. This can still be converted, although if you have a separate field for nanoseconds (or other divisions of a second) in the original UTC timestamp, then you will have to either subtract one second from the subsecond divisions, or change :60 to :59 and add one second.
And, then again, you will also have to consider the leap second when dealing with SI seconds, whether they are positive or negative leap seconds. You will get the wrong answer if you fail to consider leap seconds either way (although in the case of negative leap seconds, there might not be a "right answer" in some cases).
But, even if you do not consider these things, the timestamps will not be off by more than one second in either direction; this is not normally a problem, although in some cases it might be (which are the cases when it will be important to deal with leap seconds properly).
Sure, in theory the string 20xx-12-31T23:59:59 should never be created. But if it is created, so what? A time span is off by a second, in the positive direction. Not good, but shrug. I'm not saying it's a good thing. At time recording it's like the computer froze for a second.
Compare this to the problem of there being a unix timestamp integer that refers to two different times, which is what naive positive leap second implementations resulted in. Real time spans being impossibly negative.
Positive leap seconds are orders of magnitude worse.
Unless you're writing time keeping software, negative leap seconds can be ignored and will be "just fine". And if you are writing time keeping or benchmarking software, then this is just another thing to not have a misconception about.
> Generally UNIX time -> UTC conversion is considered to be infallible
And generally there's two seconds between N and N+2.
Yeah I'm wondering about that too. I don't think it could possibly be worse than having times like "23:59:60" pop up anywhere and messing every parser or regex up. It would just be like "huh, nothing bad (or good) happened during 23:59:58 and 0:00 according to our logfiles"
So my assumption was that Unix timestamps were monotonically increasing and that for the case of leap seconds the conversion from timestamp to UTC would take those into account and for some seconds have 2 mappings. That would keep the ordering of events, it would break assumptions like a day is 86400 seconds.
But I guess they decided to keep that invariant, which makes negative leap seconds really hard. Maybe that’s a good trade off.
The Rust standard library, which provides an API for monotonic timestamps, used to contain this silly hack (with appropriately exasperated comment) because in practice so many platforms and CPUs (Linux, Windows, BSD, x86, x64, Arm) failed to provide monotonicity despite their own documentation: https://github.com/rust-lang/rust/blob/80184183ba0a53aa4f491...
They say right there, "To hopefully mitigate the impact of this".
Having a mutex right there in the hot path of Instant::now is not great for performance. You expect getting monotonic time to be very fast generally, and some code is written with that assumption (i.e. tracing code measuring spans).
Eventually Rust just gave up. Here you go, here's your "monotonically increasing clock" courtesy of your operating system. It might go backwards, try asking your vendor to "fix" that and see if they laugh at you or just ignore you.
Sometimes the OS is broken in a way Rust can fix, for example Rust's current std::sync::RwLock actually does what you wanted on Windows, the C++ std::shared_mutex doesn't. It's documented as working, but it doesn't because the OS is broken and the fix is just on their internal git "next release" branch, not in the Windows you or your customers are running.
But sometimes you're just out of luck. Some minority or older operating systems can't do std::fs::remove_dir_all correctly, so, too bad you get the platform behaviour. It's probably fine, unless it isn't, in which case you should use a real OS.
Unix keeps the 86400 seconds as an invariant, and ignores the IS size of a second. This should work just fine for negative leap seconds too, you just make your seconds shorter instead of longer.
Of course, it's a near certainty that it won't work just fine. But it should.
I think history has proven it to be absymally bad tradeoff. If UNIX time were just actually true seconds since epoch counter then I think lot of leap second related hand wringing could have been avoided
Almost nobody ever cares for UT1 except for astronomical observations (where you are also likely using a different calendar and using sidereal days) and we already have a perfectly working system for relating local times to each other and to UTC: timezones.
The only things we should care about are local time (both as in clock time and in sun-position time) and universal timestamps to coordinate between local times and to use as canonical representations; leap seconds are useless or damaging to both of these.
We already easily accept over 60 minutes of offset between clock time and sun-position time and I do not think that 3600 seconds can be ok but 3601 or 3599 cannot.
It is also perfectly easy for a country to change its timezones or to adapt a non-whole-hour timezone (multiple countries have 15 or 30 minutes offsets)
So my proposal is that the IERS never announces any leap anything ever again and in a few centuries some countries will shift their timezone by 15 or 30 minutes.
This will be much more easily compatible with all current systems (we can right now create the timezone CETP and CETM for central European time plus 15 and minus 15) and in 400 years each at they leisure Europe/Berlin will be equivalent to CETM* (and CESTM if have failed to remove DST).
No need to handle irregular minutes or hours, no fractional seconds offsets, no need to account for edge cases that are far too easy to ignore, just keep writing code that work with timezones (as you should already be doing) do not hardcode conversion between regional timezones (Europe/Berlin) and offsets (CET, CEST, CETM) as you should already be doing just updating your timezone tables (as you should already be doing as they change often).
Just store one of:
- UTC and timezone
- dateless time with/without timezone
- date with no time with/without timezone
And you are ok, already prepared for the next few centuries of no leap seconds.
* I don't know whether it would be CETM (that is +00:45) or CETP (+01:15).
The solution is obviously to have a leap second every half year, even when the difference with solar time is too small. Just alternative positive and negative leap seconds, and for additional fun, don't have a leap second when the difference with solar has shifted (in the right direction; it should be possible to keep the difference less than 1.5 second, probably much less). We could even do this every month, just to make sure there's enough testing opportunity.
Sometimes I have wondered is there proper write up of how messy intragalactic or intergalactic communications and time keeping would be. With or without FTL communication... Relativistic effects could actually be significant. Not to mention different rotation rates, day lengths, month lengths and so on...
They don’t care about that. I mean it’s the opening paragraph…
> I just want to see it. Just once. I want to watch that earthquake ripple through all of global electronic timekeeping. I want to see which organisations make it to January morning with nothing on fire.
I agree with the author in finding some amusement in such trivial (in context) matters falling in the face of a phenomenon as fundamental as the planet's spin, something humans will likely never make a dent in.
Don’t give them any ideas! If I know humans, they’re the kind of species to figure out how to extract energy from the Earth’s rotation, overdo it way too much, and then deny that they’re the ones responsible.
> It is incorrect to consider tidal power as renewable energy. Harnessing tidal energy will pose more severe problems
than using fossil fuels. ... Tides are induced by the rotation of the Earth with respect to the gravity of
the Moon and Sun. The rotational energy of the Earth is naturally dissipated by tides slowly. Consuming tidal
energy further reduces the rotational energy, accelerates the energy loss rate, and decelerates the rotation of the
Earth.
It's completely wrong. He assumes energy will increase exponentially into the future to get to his wild claim that we could tidally lock to the moon in 1000 years. Even solar power out nuclear could not power humanity in that scenario
Certainly if we grow exponentially for a further 1000 years we'll exceed the carrying capacity of this planet, however we derive our energy. I don't think that's a very interesting result.
By "completely wrong" do you contend that using tidal energy doesn't decelerate the Earth's rotation?
(Coastlines already form natural "dams". All we would do is move the coastline inward a bit, so as the tide flows through it it spins turbines. The water gets moved the same. The energy is already dissipated at the coasts, it would happen at the dams. Total dissipated energy is the same this way. Okay, if we start putting 4 km tall dams in the middle of the ocean we might somehow meaningfully change the viscosity.)
The thesis in the PDF seems to be that somehow we can push the brakes more. Maybe. (So if we let the Sun/Moon grab some water then use the Earth to get it moving again, then it necessarily slows down the rotation. But there's already a lot of energy in moving and compressing water itself, sure it's "uncompressible" compared to gases, but there's plenty of molecular stuff to move around where energy can go. There's some tidal heating too.)
It's verbose, but in a bad way, and it's structured in a way that makes it hard to comprehend. (And the whole pro-fossil-fuel framing is just .. huh.)
The problem time keeping is meant to solve is coordination of physical movements between separated parties that have exceptionally limited and delayed communication capabilities.
All of the time issues we deal with today are in service of keeping these important properties of our civil time in tact.
In terms of computers we should happily ignore the problems of civil time, simply just use TAI, and use a provided database to convert this into "human display time" whenever necessary.
Leap seconds do absolutely nothing to fix the problems you’re talking about, for anyone. If we had never invented UTC and used TAI (+ time zone offsets) for civil time, the fact that civil time is drifting away from solar time on the order of a minute a century or so would at most be an obscure curiosity.
The question was about historical time keeping in general, not about leap seconds specifically, so I'm not sure what point you're trying to make here.
Also, astronomers care about leap seconds, and astronomy is an important tool in making observations which lead to predictions about our universe, so I wouldn't be so cavalier in labeling it an "obscure curiosity."
The whole reason to have leap seconds is _because of astronomy_. If we removed the leap second from civil time keeping, astronomers would still maintain it, because they want their observations across several decades or even centuries to use a time scale that's linked to the rotation of the earth.
That's because their telescopes are bolted to earth. So when the rotation rate changes the time at which certain features appear in the telescope also change.
They might consider using a higher precision version and make smaller updates more often but since the rate is not perfectly predictable and can be altered by local events on earth and you want all astronomers on earth to agree to the current value the second is the most reasonable unit of change for them to use.
> Because there's nothing computer programmers handle better than special cases which only occur every hundred years or so. How in the world could this be an improvement?
If it's less than 60 times as disruptive, it's an improvement.
> everybody's going to hate it at least sixty times as much as they hate leap seconds now
I doubt that.
> If something is difficult, you do it more often.
It has to be more often than leap seconds to really get those gears oiled. Unless this is a proposal to do leap deciseconds, I don't think this method reduces the pain.
> But before 1972 UTC and TAI were kept in much closer synchronisation [...] (No, I'm not advocating returning to this state of affairs.)
Coward! But seriously, I think this hurts the previous argument significantly.
If synchronizing our clocks with the Sun is still important by then, then announce it a decade or two beforehand, and make a large ceremony out of the thing.
You don’t need to announce it a decade in advance. Time zones change all the time, we already know how to handle it and it requires no global coordination. Some country announces that part of its territory is changing time zone, the tzdb is updated, and everything continues working fine for everyone. This happens a few times a year already.
The obvious disconnect is the digital bits inside my hardware clock shouldn't need to care about any of this. Then you can change it as often or as little as you like.
I assume you mean high precision clocks in computers because an actual clock won't care about half a second.
You could use TAI-ish timestamps right now, but people are going to get confused and make mistakes if your timestamps are almost UTC but several seconds off. And if UTC stays constant then you need to nudge all the time zones around and that sounds even worse.
So, you can build complex algorithms to smear leap seconds into clocks at random intervals, or you can use a published database to adjust TAI time to human time.
I think the later is less fraught with problems and doesn't require software changes in order to realize updates.
You're going to have to deal with the offset one way or another. I'm simply suggesting a means to keep the offset but not have to worry about how to realize that in terms of complicated hardware hacks.
> So, you can build complex algorithms to smear leap seconds into clocks at random intervals, or you can use a published database to adjust TAI time to human time.
That's a choice we have right now, today, and as far as I'm aware nobody chooses TAI for their systems. I think that says a lot.
> You're going to have to deal with the offset one way or another.
Most things don't really care. Oh the clock's off by 1.7 seconds, let's make an adjustment and check again tomorrow. Leap seconds are below the noise floor.
> It has to be more often than leap seconds to really get those gears oiled. Unless this is a proposal to do leap deciseconds, I don't think this method reduces the pain.
Yeah, if we're not going to abolish leap everything in UTC completely (which I think we should) then leaps need to happen at most quarterly. When the last leap second came through it was long enough since the one before that the bugs in Linux had been fixed and then unfixed.
Do we introduce an unnecessary leap second and then negative leap second every year just to keep the gears oiled? And then if we need one for reals we can increase it to two leap seconds added and only one removed. Though of course that will cause bugs in any code that isn't expecting two leap seconds to be added and assumed that there would only ever be one. sigh
Just accept that time will very slowly drift over the period of many centuries. It's really not a big deal. It's a complete non-problem that doesn't need any solving. Especially since coming up with a robust scheme that will work over the period of many centuries is quite hard (the current leap second system doesn't suffice).
I don't know what you're referring to, but as far as I know satellites can work perfectly fine without a leap second. I'm not aware of any practical advantage of leap seconds anywhere. The only difficulty in abolishing the leap second is that some systems have it incorporated in their protocol, but that's a protocol issue and not an intrinsic time drift issue.
Most satellite systems don't use leap seconds; you don't need leap seconds to have satellites. And leap seconds don't really "sync time with the earth"; that's not how any of this works. Whether it's now 13:04:00 or 13:04:27 is somewhat arbitrary and all leap seconds do is maintain a certain arbitrary definition.
We already have non-integer timezone differences. We could allow for leap seconds in that. Europe's timezone could be UTC+2:00:01 while the UK is still UTC+00:00:00
It vaguely feels like it ought to happen yearly. Yearly, but no option of a shift of exactly zero, so everybody knows it is coming every year no matter what.
I had to recreate an account just to reply to this discussion because I'm so appalled by its content. At the time of me writing this, 99% of the comment here are complaining about UTC moving to keep track of solar time or smugly arguing that we shouldn't do that.
Different time standards exist. International Atomic Time (TAI) is a strictly monotic clock based on the average of multiple atomic clocks throughout the world. UTC is defined as a tweaking of TAI to approximate UT1, a rough definition of which would be the historic mean solar time at longitude 0. UTC shifts TAI to be within one second of UT1. That's both its definition and the whole point of it even exising. I repeat, it UTC didn't track solar time, it would have no reason whatsoever to even exist.
If you want TAI, just use that. Stop complaining that UTC is not it.
"Noon" is rooted in a physical phenomenon - when the sun is highest in the sky. But "UTC Noon" is arbitrary, because we had to pick a point on the earth.
Leap seconds are trying to ensure that, standing at the point we arbitrarily picked for UTC at noon, the sun will be at its peak.
That doesn't feel like something that NEEDS sub-second precision. I mean - by walking from one side of a time zone to the other, you can have an hour or more of imprecision. https://i.ibb.co/r000S5s/caxxyddlsgp11.jpg
> Is there a single system currently in existence which can handle a leap minute?
Every system can handle a leap-hour, they happen twice a year in many countries, courtesy of DST.
So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km, fixing the error while keeping UTC monotonically increasing 1 second per second.
And to update our clocks, use the one mechanism that we already rely on comfortably - timezones. Add 15 minutes to each timezone, the same way we handle DST now.
>So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km, fixing the error while keeping UTC monotonically increasing 1 second per second.
Shifting the prime meridian 400km seems like it'd have some unintended consequences akin to the Y2K problem. Its physical location is used as a reference point in some coordinate systems, ECEF for example.
You don't need to move the prime meridian, you just need countries to update their individual time zone offsets from UTC, which is already a well-supported path that happens all the time. If we abolish leap seconds, countries would just wait until solar noon drifted ~30 minutes (which would take centuries), then just do a TZ offset update. Nothing could be simpler.
Are you suggesting a solution akin to UTC-4:00 is now UTC-4:00:01?
That sounds like a headache of epic proportions when contrasted with the alternative of a leap seconds.
No, they're suggesting a solution akin to Eastern Kazakhstan was on UTC+6:00:00 one day, and on UTC+5:00:00 the next day.
This actually happened last March[0] and I'm not aware of anyone outside Kazakhstan being inconvenienced by it at all. tzdb updates happen several times a year and everything keeps working fine.
0: https://data.iana.org/time-zones/tzdb-2024a/NEWS
No, I'm saying that e.g. Central Europe Time keeps being defined as "UTC+1" for the next few centuries until solar noon has drifted about 30 minutes away from civil noon, then CET's definition changes to be UTC+0 or UTC+0:30. This is a time zone update of the sort which happens constantly (e.g. in 2017, Chile changed its TZ offset, Haiti started using DST and Mongolia stopped using DST. A TZ offset change to account for clock drift would be exactly the same)
> NEEDS sub-second precision
To be clear, for decades, we've not sought sub-second precision. We've sought precision of a second. Maybe we should seek more-- the big problem with leap seconds is that they've been rare enough to not be tested completely well, but common enough to provoke problems.
> And to update our clocks, use the one mechanism that we already rely on comfortably - timezones. Add 15 minutes to each timezone, the same way we handle DST now.
Then everything in the world that displays time is going to need a software update when you're going to do this, or it will show time off by 15 minutes.
I do think it could be sane to let UTC's offset to drift up to +3.0 to address this temporary trend of a "fast Earth". Of course, that's going to make leap seconds rare for awhile, and it will come back and bite us when the recently-untested event of a positive leap second happens again.
> Then everything in the world that displays time is going to need a software update
Have you seen how often tzdata updates are published? There tend to be multiple each year. Stuff already should be auto updating this.
(Python, but good reference: https://github.com/python/tzdata/releases )
Yes, stuff should be, but a 15 minute adjustment within a zone suddenly is going to screw a lot of devices. Not everything that consumes UTC is internet-connected.
Heck, every existing radio-derived clock that presents time to users would be obsolete (lots of GPS, WWV/DCF watches, etc).
A lot of them have TZ-related breakage, but they usually let you set a manual hour offset or consume a daylight flag.
I think you are underestimating how long the scales are here. It could take 1000 years to be off by 15 minutes. By this time every electronic device that exists today will be either gone or in a museum.
I know it's a long time. But it's probably more like 200-250 years or so to be off by half of 15 minutes (which presumably is when you'd do a 15 minute step). And it might be a lot less than this.
In any case, I think frequent, well-tested procedures are better than an exceptional procedure on the order of decades or centuries.
> That doesn't feel like something that NEEDS sub-second precision.
It does not need to be sub-second, but sub-seconds add up over time.
The Julian calendar wasn't that far off, but it was cumulative, so to fix things it took a ten day jump:
* https://en.wikipedia.org/wiki/Gregorian_calendar
It is considered easier to have a few small(er) semi-regular jumps than suddenly having to making giant, sudden, one-off jump in the future.
We make small semi-regular changes to timezones all the time. DST switches, governments arbitrarily deciding that their country is going yo be in a different timezone (at a 2 day notice), or move the DST switch day by 2 weeks, etc etc. This is a solved problem and it happens all the time. The systems and datastructures that can deal with this (eg tzdata and the process & people behind it) are already in place.
> This is a solved problem and it happens all the time.
UTC changing does not happen all the time: what the 'all the time' thing is a display/UI offeset against UTC. Time itself is not changed in those situations, but would be with a 'UTC jump'.
The closest thing we get to universal time 'changing' are leap years and February 29, and we regularly get stories about people messing that up. And if something as common and regular as that gets fumbled I have little hope for pulling off a one-off jump of UTC.
It is coördinating the universal part that I would imagine to be the difficult part.
Then just keep UTC when it is? (ie allow its prime meridian to shift away from Greenwich) Adjust all the timezones by half an hour in a few millennia. It’s really both fine and up to our grand-grand-grand-grand-etc-children to decide.
Really, this is a non-problem.
This really doesn't solve anything either. Attempting to treat time as something that ticks towards the future at a consistent rate relative to all observers is already broken. The Earths rotation is slowing down over geologic time. Even on short orders things like earthquakes can change rate of rotation of the planet. Start putting stuff on spaceships and different planets and you start seeing how wibbily wobbily time really is.
Just like we have to focus on making application secure, we need to ensure our applications don't shit their pants when applications change time in unexpected ways.
> It’s really both fine and up to our grand-grand-grand-grand-etc-children to decide.
I'd rather build gradual adjustments into our systems so that they have to be resilient to this sort of thing. Sure, leaving it up to our distant descendants is enticing, but then they're going to have a Y2K-sized problem to fix. I'd rather leave a legacy of systems that were designed to be resilient.
> then they're going to have a Y2K-sized problem to fix.
No they aren't. tzdb updates happen several times a year already, and you don't notice.
The suggestion I was responding to was to basically stop doing this.
I thought it was suggesting exactly the opposite: that we handle this with tzdb updates, not leap seconds.
Yep!
(assuming our grand-grand-grand-grand-etc-children still have something like a tzdb)
The universal part is alread coordinated, the problem is that it keeps adding and removing seconds with no regularity and little advance notice.
It feels like you missed the main point. Time-zone changes are already very easy to handle and are sufficient for dealing with this problem without having to use a leap second or leap minute ever.
> Time-zone changes are already very easy to handle and are sufficient for dealing with this problem without having to use a leap second or leap minute ever.
TZ changes are a display delta against UTC. The closest thing we get to universal time 'changing' are leap years and February 29, and we regularly get stories about people messing that up. If something as common as February 29 is fumbled, what are the odds of pulling a one-off event?
And as someone who was a sysadmin when the US changed its TZ rules many moons ago, the sudden rule change was anything but straight-forward given the fairly static nature that they had been for the long history of software development that had occurred until that point: a lot of software is US-developed, and there was little/zero consideration to updating rules. (Though I think that event caused a lot of developers to be more understanding.)
The point is we don't need to change universal time. Thousands of years from now, when solar time drifts away from UTC enough for a particular country to care, that country can change its time zone. There doesn't need to be any global coordination and the process will be gradual enough that nobody will notice.
The EU already fails to agree on dropping DST (and adjusting time zones in the process), because member states will be affected differently, and neighboring countries that should really be in different time zones benefit from being in the same zone. I doubt they could agree on shifting their time zones, because invariably some countries would get the short stick.
I keep repeating this point but for some reason people keep ignoring it. Countries do not have to agree to change time zone. They can each change it whenever they want.
The point is they will not want to change their time zone to a different one from their neighbors if they are in the same zone, because that has economic downsides. And the neighboring country will not want to change along because winter mornings will be too dark or whatever. It’s exactly the issue that currently prevents dropping DST in the EU, although a majority would prefer not changing clocks twice a year.
I think that getting all of Europe to change time zone offsets by 30 minutes once every 400 years is within our power.
> I think that getting all of Europe to change time zone offsets by 30 minutes once every 400 years is within our power.
It took about 400 years for all countries to finally go from Julian to Gregorian. :)
In 400 years we can define new 30 minutes shifted timezones and in 400 - 500 years governments can slowly change their official timezones (maybe at summer/winter time they shift 30 minutes instead of 60). It does not feel like a big issue.
> So let's just wait until there's 15 minutes of error - a couple of millenia from now.
This might already happen in 200-300 years, because the delta increases quadratically: https://www.ucolick.org/~sla/leapsecs/deltat.html
I wouldn't even suggest a solution. Let the people thousands of years in the future figure it out. Working out solutions now is like asking people from the time of Jesus what we should do about the clock for a worldwide computerized network.
> So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km
Perhaps a couple of millenia down the road, we have the technology to speed up/down the rotation of the Earth in order to keep it synced with UTC.
> Every system can handle a leap-hour, they happen twice a year in many countries, courtesy of DST.
Any DST aware system I've checked handles this as a timezone change rather than changing the underlying time, expressed in UTC. Even for locations where DST's onset removes an hour rather than adding one.
We already have that system, and it's called TAI. You are free to use TAI instead of UTC in your computing projects, and don't have to try to change the definition of UTC.
> You are free to use TAI instead of UTC in your computing projects, and don't have to try to change the definition of UTC.
Not if you want to interoperate with basically any other system that uses time.
Which is a very good reason to abolish the leap second in UTC to make it the same as TAI time. We can then make a new standard that includes the leap seconds and add them to that (which computers will only ever deal with when they format datetime).
Leap seconds are absolutely part of the local datetime conversion functionality of time and not part of the counting functionality. Unix time should never have been different from TAI time in the first place but somewhere along the line some idiot made the absolute undeniable blunder of putting the seconds offset of the suns position relative to earth in the counter of seconds rather than putting it in function that formats the local datetime.
Anyway here we are. It’s totally fair that UTC includes leap seconds but unfortunately they passed on UTC as is into the unixtime seconds counter which makes no sense since computers don’t print UTC datetime directly anyway, they have a special date() formatting functions that could easily and problem free add seconds as needed.
So what’s the solution? Well telling everyone to suddenly adopt TAI is difficult. But we could just abolish leap seconds from UTC effectively migrating everyone without them realising it. Now I know that sounds odd. After all this blunder wasn’t done by the UTC creators, it was the Unix guys that fucked up here. UTC is literally meant to track the sun after all. But still it’s the easiest fix and we can always create a new UTC, UTC_leap_seconds, that we can use in our datetime printing functions if we want. Abolishing leap seconds from UTC and thus Unixtime will make the world run more smoothly. It’s also been planned as we speak so you don’t need to do anything but wait! :)
I don’t disagree!
> Which is a very good reason to abolish the leap second in UTC to make it the same as TAI time. We can then make a new standard that includes the leap seconds and add them to that (which computers will only ever deal with when they format datetime).
But, once again: that already exists!
Sure but sometimes we have to do things twice because of a fuck up.
Because changing the definition will make old-definition systems magically interoperable with new-definition systems?
It’s not changing any definition, it’s ceasing to add any new leap seconds to UTC. Which is what the BIPM is planning to do anyways!
I'm trying. I don't even know if rust or c++ have tai yet
This would be a feature of the underlying platform and nothing to do with the programming language.
"move the UTC prime meridian"
We'd have two prime meridians. One for time and another for longitude. (Not a deal breaker but we'd have to plan for it.)
We have many prime meridians for longitude. The location of 0° on Earth is not the same in every datum.
We also moved the traditional prime meridian by a hundred meters back in 1974 with the adoption of the IERS Reference Meridian.
Said another way, the prime meridian adjusted by (at max deviation) 0.1km 50 years ago and hasn't been changed since.*
*Though on a small scale, tectonic movements fuzz the idea of "location" in general.
I vote to correct the clocks once a century. Then it'd be infrequent enough to have a big celebration rather than being annoying.
I think it's weird how people react with such horror to the idea that maybe, just maybe, it wouldn't represent any kind of problem to the people of the 23rd century if 12:00 didn't correspond to the instant the sun was directly overhead, but instead a minute past. Nor would it cause any issue for people thousands of years from now if 12:00 was in the evening or the morning or any other part of the day or night. For those future people it would simply be the way things are, and it would stay that way their whole lives.
Noon already does not correspond to the sun overhead. Timezones, and IIRC the time of year and inclination relative to the equator matter too.
However, irrespectively, it's basically never solar noon at noon if someone is using time zones rather than local solar time, which of course would be a custom timezone for that exact location.
This article that I just came across does a nice job at explaining some of the nuances of solar noon https://www.timeanddate.com/astronomy/solar-noon.html .
The time of year does matter a bit, but the effect is smaller than the effect of timezones. Their equation of time article includes a nice graph of the variations in time of solar noon at Greenwich. https://www.timeanddate.com/astronomy/equation-of-time.html
> This article that I just came across does a nice job at explaining some of the nuances of solar noon https://www.timeanddate.com/astronomy/solar-noon.html .
And a related thing, the analemma - the sun's position at the same place on earth at solar noon over the course of a year doesn't resemble an arc, it's a figure-8: https://en.wikipedia.org/wiki/Analemma
Many parts of the world move forwards and back a full _hour_ every year. We complain about it but it’s mostly ignored. A gradual drift of a couple of minutes is fine.
I work in Arizona, and some of our software calls APIs on a server hosted in California. The California server expects timestamps in requests to be in Pacific time, with no timezone in the timestamp, and expects them to conform to daylight savings rules.
This gets very hard to reason about because Arizona doesn't _do_ daylight savings. Like, what happens when we request 24 hours of data from them, on the day daylight savings time flips over? Do we want midnight-to-midnight data, or do we actually want 24 hours of data, which might wind up timestamped differently since there's a duplicate 2AM one day and a missing 2AM another day.
A few years ago we had a contractor write some extremely messy code to handle cases like that, and soon it's going to be my job to try and refactor it into something readable.
It's surprising how many vendors of security product refuse to use UTC for timestamps and insist on using the local time of their bay area data center. The number of edge cases that arise from DST issues that are significantly reduced, if not completely eliminated, by using UTC should be reason enough for security product vendors to see it as a core best practice.
I'm amazed to hear anyone doesn't use UTC, I'm not a professional developer and I remember learning, just while teaching myself the basics of PHP & MySQL as a teenager, that it's best to have databases store either UTC or a Unix timestamp (which afaik is essentially the same as using UTC except that it's less easy for most people to read at a glance) and to do the conversion to any local time zone wherever users interact with it.
I have a rule of thumb that software works progressively worse the further you are away from the Bay Area - both geographically and culturally. For example, we use roundabouts (traffic circles) everywhere here in Australia and google maps still gives pretty terrible directions when driving on them. I was shocked the first time I drove on the 101 just how good the spoken directions are - but it makes sense given the actual Google maps engineers drive that road. If the directions were bad there, they would get fixed.
I shudder to think how many bugs must show up for people who use right-to-left languages or use non-ascii charsets - especially before Unicode & emoji were popular. I’m ashamed to admit I don’t even know how to test if my software works properly in languages like Arabic.
Of course software made in the Bay Area assumes the whole planet uses pacific time. I’m sorry to throw shade, but that’s entirely in character for the area.
> I have a rule of thumb that software works progressively worse the further you are away from the Bay Area - both geographically and culturally.
It's not just software. EVs struggle with cold and hot climates. They'll get better, of course. But with the engineers living in mostly temperate climates, conditions outside the development environment get less upfront attention.
The two worst offenders I can think of with regards to using local time were Rackspace, and Southwest Airlines.
Not in the Bay Area, but every other west-coast company I've been involved with is pretty militant about using UTC, typically due battle wounds from communication challenges or time-related bugs.
I would be very curious to hear which other major companies are deploying systems on local time in 2024.
Google runs on Google Standard Time which is UTC+8 aka US west coast.
> either UTC or a Unix timestamp (which afaik is essentially the same as using UTC except that it's less easy for most people to read at a glance)
UTC has leap seconds, unix timestamp doesn't. It's defined to have 86400 seconds per day, so there's no place to put a leap second. Instead, it either duplicates a timestamp or does "leap smearing" - slightly changing the duration of a second around where the leap second is.
They both skip over leap seconds unlike TAI time, they just handle the leap second subtly differently. He’s right to say it’s essentially the same.
The most amazing of these exceptions is Microsoft Windows 11, which still uses local time on the hardware clock, a legacy of decisions made over 40 years ago. Raymond Chen defended this practice (20 years ago) https://devblogs.microsoft.com/oldnewthing/20040902-00/?p=37... . It's possible to make it use UTC, but it requires registry hacking.
Why would anyone choose to use local time for anything other than display? That just seems way harder even if you don't have customers from other timezones.
> Why would anyone choose to use local time for anything other than display?
You need to store it for certain applications, e.g. timetabling. if school starts at 9am, it starts at 9am local time, and if local time changes (DST, or more rarely a change in the time zone rules) then school start time runs with it. Or similarly, if a commuter train timetable has it stopping at a certain station at 7.05am, that’ll be local time in the local time zone.
I arrived 1 hour late to an online meeting once in which I was scheduled to give a talk. The root cause was this: I (in Australia) was subscribed to the event calendar. The event was actually a reoccurring event at the same time every month in UTC time. But day or so before the event happened, daylight savings changed in LA - which for some reason was the time zone the calendar was set to. As a result, the meeting in my local Australian time drifted by an hour. Unfortunately, only some people used the online calendar. So many people (including the organisers) showed up on time.
Time zones are a curse on humanity.
Are you saying the calendar was set the "DT" (daylight savings time) and not "ST" (standard time) so when it actually flipped the calendar adjusted 1 hour in the wrong direction? heh, yeah that would be very frustrating, glad it wasn't like a final exam (for students) or an oral presentation in front of a client (for consultants/professionals).
edit: not trivializing missing the talk, i would be pissed.
DST is in opposite halves of the year in different hemispheres, and also the transition dates will be different in different DST-using countries even in the same hemisphere.
So the timezone difference between US and Australia (or at least their DST using parts, since in both countries some states don’t observe DST) is 2 hours more in one half of the year than the other. And it changes four times. In January, Australia has DST and US doesn’t. Then in March US starts DST and moves one hour away. In April, Australia ends DST and moves another hour away (in the opposite direction). In October, Australia starts DST and moves an hour closer to US. In November, US ends DST and moves another hour closer to Australia.
Yeah thats right. I was definitely pissed.
Time zones are totally fine. They're unreasonably hard to do math with (ahead/behind +/- just refuses to stick in my brain), but they massively simplify life most of time they come up.
The thing that's a curse on humanity is daylight saving time.
I really hate when someone writes a time + dst/pst/cet/whatever, rather than using utc, or even at least adding the utc time additionally.
Yeah, timezone abbreviations are problematic because how am I suppose to remember what time zone offset “EST” is? Here in Australia, we have “EST” too, but ours is UTC+10 not UTC-I forget
You can look it up. Or ask Google “time now in PST”. (“Pacific standard time” - which means San Francisco, obviously. It’s not like other people live near the Pacific Ocean).
But there’s PT (pacific time), as well as PST and PDT (pacific standard and daylight savings time) if you need to be specific with whether or not daylight savings is happening.
EST, according to Google, is the east coast of America when daylight savings is not happening. For Sydney and Melbourne, you want AEST / AEDT / AET depending on if you want to specify Australian east coast standard, daylight savings or current time (which changes depending on the date).
It’s all hilariously exhausting to keep track of. Simple enough you think you can remember it, but complex enough you will miss your meeting even though you checked twice because the calendar was set to the wrong timezone and it didn’t matter until today. The relative time between Australia and California changes 4 times a year by 1 hour, depending on the local daylight savings time in both countries. I hate it.
> EST, according to Google, is the east coast of America when daylight savings is not happening. For Sydney and Melbourne, you want AEST / AEDT / AET
Although AEST/AEDT are probably more common-in part to avoid confusion with American EST/EDT-people use EST/EDT for the Australian time zones too - random example: https://www.support.transport.qld.gov.au/qt/systemmaintenanc...
Some computer systems (probably designed by Americans) want timezones to have abbreviations but insist they can only have three letters, so in those systems the Australian timezones have three letters. I definitely remember seeing EST meaning UTC+10 on Unix systems before
I try to refer to local time in an area I'm not in as <location>-time rather than the timezone's canonical name to avoid this kind of confusion. Then use a world clock to tell when that is. e.g. "That livestream should start at 4:30pm Vancouver time."
> they massively simplify life most of time they come up.
I have coworkers and friends in different timezones, and timezones do literally nothing but complicate coordination. Even if it's a small friction, they are 100% friction.
As far as I can tell, the main benefit of timezones is that it allows people within the same timezone to converse as if timezones don't exist. Which would also be the case if timezones didn't exist.
Historically speaking, the alternative to time zones is not one unified time, it's thousands or millions of time bubbles for each town's solar noon.
Yes, but we're not speaking historically.
but school starts at 9am the nth of september not 2024-09-15 09:00:00
I know a bit about the computer system at our children’s school. I only have access to the parent portal, but that’s enough to give me some idea how it actually handles things. Plus I used to work for a university, and I got a good look at the internals of its system - and timetabling isn’t fundamentally different between primary/secondary and tertiary, just it gets more complicated as you move up.
So, to answer what I think you are saying - normally you divide the day into chunks (“periods”). At our children’s school, it is primary, there are only two notional periods a day (morning and afternoon), when our son goes to secondary school next year (which appears to use the same software) there will be several periods a day, one per a subject.
Anyway, in the system, a period is a class, not just in the academic sense, but also in the OO sense, and as such it has instances - “morning period” starts at 8.35 am local time any day the school is open. So that start time would be stored without a date, just a time plus time zone. But then, there is an instance of “morning period” every one of those days, which starts at a particular instant in time - today it starts at 2024-07-04T08:35+10:00. And yes, you could store that just in UTC, and convert to the school’s local time on display.
I suppose there are three main data types you really need: (1) date without time (2) local time in specific timezone (3) UTC instant
For (1), whether you need the timezone or not depends on the use case. For stuff like dates of births, you generally won’t know and don’t really need to know the timezone in which they were born. But, for other applications, it becomes important, since Wednesday afternoon in the Americas is Thursday morning in Oceania and eastern Asia, so whether it is Wednesday or Thursday depends on your timezone. People expect days to start and end at local midnight, not UTC midnight - which for me is 10 or 11 o’clock in the morning.
For hire dates, many jurisdictions have employment laws that have different rules depending on how long you’ve worked there. So you need to know how many days since hire to know what legal regulations apply to the employee. And obviously that is meant to be calculated in local time, if you do it in UTC or HQ timezone it could be a day out, which might cause legal issues. (e.g. in some jurisdictions it is easier to fire an employee in the first six months, you wait until the last day to terminate them, except because you got the day off by one, that was yesterday, now you have terminated them illegally)
If your application's use is local enough that more than one timezone isn't a concern, and doesn't much (or at all) care for things that span overnight, so you don't have to worry about adding/dropping an hour to the length of things when some sort of DST event happens, just using local time across the board is simply easier.
Of course as soon as one of those assumptions is not 100% true, using UTC internally and local time for display is usually by far the better option (though there can still be difficulties there – time is never as easy as you'd think it should be).
The trouble comes when people use to working local only (timezone wise) slap together a PoC of something that might need timezone awareness, and don't fix the deficiency at any point as they progress through PoC->prototype->alpha->beta->v1. The longer you leave the change the harder it is to do, and it not being easy is why once something nominally reaches V1 (or often at first alpha release) such a fix is seldom ever made.
Timezone awareness has improved massively in recent years though. I think some cloud providers have accidentally helped there by defaulting to UTC (for instance all AzureSQL DBs default to UTC for everything, as do VMs and other things in Azure). Though here in the UK minor issues due to bad assumptions are still common when we transition back or forth between GMT and BST.
Yeah, and even if those assumptions are perfectly fine today, they are unlikely stay that way. When they do, going back and fixing everything else is a massive pain. Even ensuring everything is in localtime can be a pain; someone decides to add a database you didn't have before and didn't pay enough attention to its configuration? Too many landmines.
The way to avoid this pain is to just use UTC on day one, regardless of requirements. Hard and fast rule that everything needs to be UTC. Need to display it? Converting to local time is trivial.
Same thing for text. Use Unicode unless otherwise specified.
> just use UTC on day one, regardless of requirements
That can cause extra concerns for always-in-one-timezone systems where you might care where midnight falls (“did this event happen today or yesterday?” is a question that needs extra steps to answer, for instance). Nothing complicated, but extra work you might want to skip at the quick PoC stage.
But yes, beyond PoC work and all but the simplest other work, I'd agree with UTC all the way from the ground up.
Yup. The only exception I could think of are prearranged local times, e.g. the meeting will be on -future day- at -local time-. In that case, if, say, the time zone changes, the meeting would still be at the same local time and not move.
True, but also for the past, actually.
Because DST might be a thing right now in that zone, but may no longer be next year, in which case the historical DST is needed to refer to times in the past.
Same for dates a bit further back when countries changed calendars and some days are missing.
So, we basically need a mapping of UTC -> local time as a function of time, and store this forever.
(For durations, we might need to have a mapping from TAI to UTC as a function of time, because a leap second messes with duration length. Smeared leap seconds are even worse in that regard)
About half of the world would 15+ minutes away from sun directly overhead at noon if hour-aligned time zones worked correctly, leapseconds are "solving" a "problem" at a level of precision wildly at odds with actual usage.
Even besides daylight savings time, timezones exist. England and Spain are on a vertical axis, yet the timezone differs by 1 hour. Cross the border from spain to portugal and time jumps a full hour, so there are people living 100 Meters apart with 1 hour time difference.
Timezones are political and economic statements (and sometimes even religious - https://github.com/eggert/tz/blob/main/africa#L853 ). Things like China being all one timezone or India changing to IST after declaring independence https://en.wikipedia.org/wiki/Time_in_India#After_independen... . An example of an economic change was https://en.wikipedia.org/wiki/International_Date_Line#Easter...
Trying to make sense of them as purely time keeping artifacts is bound to have misunderstandings.
I've heard that this is why Spanish people go to bed so late. They are going to bed at the same solar time, it just seems later because of the time zone they are in.
https://www.bbc.com/worklife/article/20170609-its-time-to-pu....
> The Spanish also go to sleep later than their European neighbours. According to Eurostat, Spaniards go to bed, on average, at midnight, compared to Germans at 10pm, the French at 10.30pm and Italians at 11pm.
It's not that many parts of the world. DST is a very western "problem" that most of South and Central America, Africa and Asia simply don't have to deal with.
We're the exception, not the rule.
Funny that you only consider North America as 'western'.
Brazil, the largest country in South America, had DST until very recently (2019). A large chunk of South America observed DST at some point. Some stopped in the 90s, others stopped much more recently.
The sun is everywhere. Time zones (and the reasons that spawned them) after everywhere. Why would they be magically free of it?
Daylight savings time is not in a majority of countries. See the map on Wikipedia: https://en.wikipedia.org/wiki/Daylight_saving_time
Note that political timezones are not baked into Unix time, whereas leap second corrections are.
Its not quite the same problem. Timezones are a transformation applied on top of UTC. If you are writing code, you are transforming the always increasing UTC to a more or less arbitrary dates and times.
Moving backwards means you (your code) experiences the same time twice.
It is not exactly same, but it can be framed as the same problem by requiring every nation to change their own time zone once in a while. As long as the "once in a while" is not frequent (unlikely to happen before 2500, and should happen less than once per century for next 10K years), this should be okay.
Keep in mind that the earth is round and timezones switch an hour by area, so there is always some drift between the suns position and midday.
So from my point of view, they were spot on
You might be surprised to learn that there are time zones that are not an integer number of hours different from UTC.
I'm always open to change my mind, but I struggle to see the relevance of that in this context.
Are there timezone areas in the world which change their UTC differential fluidly throughout the year and by the yard to pin midday to the highest position of the sun?
I'll definitely say that that'd not only surprise me but blow my mind if true!
If there isn't ... Then what was your point?
You claimed that timezones change an hour by area. That's not the case. That's my point.
So you don't have a point, because the only "claim" I had was - agreeing with the grandparent comment, because:
there is always some drift between the suns position and midday
Your point is about as coherent as saying CO2 levels in the air aren't going higher, because the sea is blue
It makes a lot of sense to not care about a slight amount of drift. But that already exists: that's what TAI is. Why make UTC into another TAI just slightly offset? Why not just switch to TAI? Or, if the 37 second difference between UTC and TAI is the problem they can make a new TAI-minus-37.
What makes no sense is taking something useful, UTC, and redefining it out of existence. Then what time do you use if you really do care about drift? Do we invent a new UTC?
> Why not just switch to TAI?
That would be great.
> Then what time do you use if you really do care about drift?
Nobody uses UTC because they want to know where the Sun is to the nearest second. People who actually need to care about variations in the Earth's rotation speed (e.g. astronomers) already need far fancier stuff than just UTC. People use UTC because someone else made a mistake and decided they should use UTC, like a government standard, or an operating system vendor, or whatever. Unfortunately the best way to correct all those millions of mistakes is to redefine UTC rather than convince everyone in the world to simultaneously switch to TAI.
> taking something useful, UTC, and redefining it out of existence
I question that UTC is useful. What utility does it have over TAI, outside of interoperability with other people who are using UTC? Again, anyone who actually needs to care about Earth rotation speed changes already needs to use something better than plain UTC, and my argument in my original comment is that drift that is small on a scale of a human lifetime is not an actual problem for anyone alive today or in the future.
>That would be great.
Well whats stopping you?
> interoperability with other people who are using UTC
> Why not just switch to TAI?
Getting the world to switch timescales is orders of magnitude more difficult that redefining currently used timescale. The latter can be done in the BIPM backrooms by small committee, the former needs action and agreement from pretty much everyone.
Also, very few people today have the sun directly over their head at noon. If you don't live at the prime meridian, it is an abstract concept. And even if you do, there may be DST. In some countries, you can be hours off.
Few people actually care about the precise earth rotation, and there are time bases for these people that are better than UTC anyways. Sunrise and sunset are important, but the middle of the day, not so much.
Riffing on “if it’s painful, do it more often”, I wonder if mandatory leap seconds every year, but trueing up the delta from N years ago, would be a good compromise? Regularity makes it easier to plan, and 6 months’ notice is not really enough for many OS distribution paths (eg IoT, embedded).
Since the list of delta updates is queued, you could bake N years of updates into your system if it’s a fire-and-forget OS. A number in between 5 and 10 seems reasonable to me, but seeing as we are discussing living with 50 years of drift it could be higher. And sure, for this to work, allow non-integer deltas again; or just have a rule that you round the applied adjustment down.
Seems no harder to bake in the last 50 years of leap seconds as to include to Olson TZ database in your distro.
If you go with that, just move it in the correct direction every year, regardless if you make the absolute delta bigger (you'll fix it in a year by going backwards).
If this is not enough to ping-pong around the correct result, because you're drifting too fast, just increase the rate of changes, now that the system is well oiled.
That said, we should not have leap seconds, just timezones around TAI. If UTC wants to be a timezone that changes every six months with a second offset, so be it. Bureaucratic systems are already in place to solve that.
That's actually a good idea in the short term (i.e. less than one century). The length of the day (LOD) is thought to be linearly increasing in the long term though, so ΔT, the cumulative difference between past SI days and actual LOD, should be quadratically increasing and a delayed leap second adjustment would be too slow to catch up at some point in the future.
Yet another possibility is to put any possible kind of leap second at the beginning of the year. The only requirement set by past CGPMs is that dUTC = UT1 - UTC should be in [-0.9, +0.9] seconds, so we can always put a positive leap second when dUTC is in [-0.9, -0.1]s and a negative leap second when dUTC is in [+0.1, +0.9]s, dramatically increasing the number of leap seconds without violating the dUTC requirement. If the dUTC requirement is a bit more relaxed (say, [-2, +2] seconds) then we can even mandate leap second every year!
But well no, I'm strongly against the current form of leap seconds because it is already problematic in the short term and will be yet useless in the long term. Recall that ΔT is expected to be quadratically increasing in the long term; this means that the effectiveness of leap seconds is limited to the point when any small fixed number of leap seconds per year (12 in the current system, but anything larger than 1 will cause a problem) is no longer sufficient, and that point is not far from the point where the magnitude of ΔT is significantly large and leap seconds are absolutely required. As DST demonstrates, the world is probably fine with ~2,000 seconds of ΔT, which wouldn't happen before 2500, but at that point we would already start using double leap seconds per year at average. We would probably abolish leap seconds for that reason alone.
I have never understood why POSIX and NTP timescales work the way they do. They are positively bonkers when it comes to leap seconds. Time isn't even monotonic during the transition, because the epoch itself is redefined.
Contrast this with the GPS or PTP timescales, which simply count seconds since a well-defined epoch. Formatting the date and time for humans to read is a sensibly separate process.
But then GPS went off the rails and used a 10-bit number for count weeks, resulting in the 19-year week number roll-over (WNRO) problem. A few bits more would have solved a lot of problems..
Ref: https://en.wikipedia.org/wiki/GPS_week_number_rollover
Given that the first GPS satellites were launched in 1978, saving a few bits was standard practice at the time -- bits were expensive. Code of the time also often had two-digit years (the infamous Y2K problem).
A full GPS navigation message is 37500 bits.
I'll admit that it's not that simple: there are repeating fields in that message to avoid having to 12.5 minutes between each update.
They could have kept the week number in the repeating message at 10 bits while having a non-repeating MSB?
It's 1500. The full data set is 37500 but you get there by spreading the larger message across several subframes. The full data set includes ephemeris data for all other satellites. It's precisely as long as it needs to be. This also means there is a built in fixed maximum number of satellites in constellation.
The time code gets 300 bits. It lasts 6 seconds and it's repeated every 30 seconds. Critically, it will always occur precisely on the top (:00 seconds) of the minute, or the bottom (:30 seconds) of the minute.
Interestingly, most of the time code is used for /correction/ parameters, as precise values for these are required to accurately calculate time. Satellites themselves drift in performance as they age so these parameters are not static for the lifetime of the deployment.
If you want to get into the nitty gritty, again, made in the 70s, so it's pretty approachable today: https://www.gps.gov/technical/ps/1995-SPS-signal-specificati...
The full 37500 bits data is set is called “GPS Navigation Message”, or at least that’s what the ESA website call it. (https://gssc.esa.int/navipedia/index.php/GPS_Navigation_Mess...)
And, yes, I understand that time message gets sent at a much higher rate, hence the “it’s not that simple” part.
But I still have a hard time to believe that it would have been impossible to find 2 or 3 bits in the overall message to include the MSBs for the weeks. GPS units with built-in support for WNRO (due to permanent storage) would be able to ignore it, other units would be able to correct the epoch after 12 minutes (or a multiple in case of data corruption.)
It would have been possible but it would have required a trade off against the other data in the message; however, the goal of GPS is to provide accurate position data, not to provide convenient "calendar time" to individuals. Which is why they spent so lavishly on high precision correction parameters and so sparsely on low precision time of calendar parameters.
From the start, GPS has been used for accurate time keeping as well. And for later versions of the GPS protocol the week number was increased to 13 bits.
https://www.gps.gov/systems/gps/modernization/cnav/
> I have never understood why POSIX and NTP timescales work the way they do.
Posix committee thought it would be very convenient if you can get time of day by doing time()%86400.
Very convenient indeed...
I don't even see the need for leap seconds at all (in either direction). Why should anyone care? All times are relative to some arbitrary fixed point in time anyway, so why are we so hung up on maintaining the status quo?
Aside from the fact that just by ignoring the problem it'll probably go away - we've just had a period of adding a load of leap seconds to roughly compensating for the Earth rotating "too slowly" overall, which for a system that's inherently irregular and actually speeds up and slows down all the time, and just happens to have been "too slowly" ON AVERAGE. It now seems hat the rotation speed, on average, is "too fast" and now we need to undo some of that adjustment. If we'd just left it alone, it'd have been fine.
And for all the hassle these leap seconds cause, what exactly has been the benefit? Since 1972, we've had 27 seconds added. 27 WHOLE SECONDS. That would have made absolutely no difference to anybody's life if the sunrise and sunset was 27 seconds later.
Just think, in 100 years, when your great grandchildren are enjoying their life, we might be a whole minute wrong. And if you went the other direction, back as far as all of recorded human history, and we might be out by an hour. Many of us are routinely forced to have our clocks out by an hour for "daylight savings time" every year anyway.
For the very few cases where it might be useful to know the ACTUAL difference between the rotation and alignment of an abritrary fixed point on earth and an arbitrary fixed point on the sub, then THEY can use they own clock for that specialised purpose. And maintain a fixed adjustment to the atomic clock based time that everyone else uses, and they don't even have to round to a whole second for that - they can say NASA time is TAI+1.234s for instance and the only people who need know or care is NASA themselves.
A significant number of systems related to Earth’s rotation (like navigational systems) rely on the difference between UT1 and broadcast UTC to be less than 1 second. If UTC were to change to a constant offset to UT1, those systems would need to be provisioned in an alternative manner to receive a time signal with the same guarantee. Basically, we would still need what is now broadcast as UTC, just under a different name. And if we have that, we might just as well keep civil time synchronized to it.
> Since 1972, we've had 27 seconds added. 27 WHOLE SECONDS. That would have made absolutely no difference to anybody's life if the sunrise and sunset was 27 seconds later.
The delta increases quadratically though due to Earth’s rotation slowing down in the long term, so the problem will only get more severe.
> A significant number of systems related to Earth’s rotation (like navigational systems) rely on the difference between UT1 and broadcast UTC to be less than 1 second.
Can you name some of these systems?
For most civil purposes, it really doesn't matter but we're techies and it's in our nature to obsess over details like this, often to the determent of ourselves and the systems we're trying to maintain. It appears many of those with the most influence over setting the example for such things in the civil realm have indeed discovered the leap second is far more trouble than it is worth and now it is falling out of favor. For astronomical, aeronautical and other scientific purposes, they'll continue to deal with the hassles, but for the rest of us, it appears the era of leap seconds is slowly drawing to a close.
Leap seconds are both unnecessary and useless at solving the problem they are intended to solve.
If you care about the position of the sun to second precision, then time alone tells you nothing - you need location too. Ironically, most people get their location these days using GPS which is based on TAI, not UTC with leap seconds.
If you don’t care about the position of the sun to second precision then leap seconds are a nuisance.
There’s zero reason to have leap seconds in the definition of time. It should be a database, like tz, that software that wants Earth rotation updates for calculation of sun position can download and incorporate into its calculations for increased accuracy.
The fundamental problem with leap seconds is that you can’t predict what the leap second delta between UTC (legal time) and TAI (absolute time) will be in the future. That’s unacceptable, I should be able to know how many seconds there are between 1 July 2024 and 1 July 2026 without needing to wait for a Time Lord to determine it.
> If you care about the position of the sun to second precision, then time alone tells you nothing - you need location too
Unless you are using time and (celestial) observations to determine your location. It's not coincidence that US Naval Observatory (and its peers) is one of the key origins of UTC.
> without needing to wait for a Time Lord to determine it.
They're not to blame - Davros is responsible for the leap seconds.
> but we're techies and it's in our nature to obsess over details like this
Speak for yourself! Part of good engineering is knowing when over-engineered perfection is useless. The inventors of UTC/leap seconds did not, and made a serious mistake the rest of us have had to live with.
> You've reached a situation where campaigning for the whole world to change the way it measures time is simpler than fixing your code?
It isn't just a code problem. Since leap seconds aren't predictable, you have to somehow distribute information about new leap seconds to everything, which is especially difficult for devices that aren't connected to the Internet.
And as the article mentioned, there are multiple ways to deal with leap seconds, and there are tradeoffs involved in choosing which one, and depending on the circumstance different ways. And since different methods work best in different situations, that can result in inconsistencies between different systems.
I gotta say I like this QNTM cat. Wrote Hatetris, "There Is No Antimemetics Division," and Absurdle. A fun explorer of adversarial computing environments. Pretty interesting
My team is kind of a miniature qntm fan club. We include copies of antimemetics as a new employee gift.
Holy shit, this is a world collision I wasn’t ever expecting to see. Thank you for pointing this out, “There Is No Antimemetics Division” is possibly my single favorite piece of fiction I’ve ever read, and I would’ve completely missed this connection otherwise.
qntm, I know you're reading this. As someone working on software that works on ships (aka, software that needs to change timezones and locations often and still maintain contiguous millisecond accuracy of all shipboard equipment events), this article has caused me significant psychological damage.
There Is No AntiTimekeeping Division ...
> still maintain contiguous millisecond accuracy of all shipboard equipment events
can you elaborate on the purpose of this? is it for legal requirements? some kind of "black box" recorder? why does timezone matter for such low-level event data?
Naval boats cost a fortune. The telemetry from the onboard engines/machines/computers needs to be in sync, and they don't always have compatible timekeeping systems, so sometimes it needs to be translated into a common format and recorded in our db's.
If something goes wrong, a lot of parties both internal and external are interested in reviewing the (extremely detailed) logs for the purposes of insurance, or court-martial, or whatever.
Maybe there should be an analog of the Kardashev scale for civilizations capable of adjusting the rotation speed of their planet in order to make timekeeping easier.
I feel like we'll get a (less physically _real_, but much more impactful) run of this "make it to the next day unscathed" adventure in 2038. Only 14 short years...
Does anyone have an actual example where leap seconds are a problem? Specifically one that can't be solved simply by using Atomic Time? Maybe then we can figure out what the problem we're trying to solve is.
Few people or systems even interact with a clock that is precise enough to detect the difference, and instead rely on clocks that are 100's or even 1000's of times less accurate than what would be required to even detect a leap second. And these clocks undergo thousands of corrections between leap seconds without a complaint.
We add an entire day to the calendar about every 4 years. It's not a problem because everyone is aware of it. So I think the only real thing that needs to change about leap seconds is awareness of them.
Leap seconds are needed in civil time because people's schedules are still dominated by the Sun. Not to the second, maybe not even to the hour. But the leap second was chosen because it's large enough to be infrequent, and tiny enough that only a tiny fraction of systems will notice.
> Does anyone have an actual example where leap seconds are a problem? Specifically one that can't be solved simply by using Atomic Time? Maybe then we can figure out what the problem we're trying to solve is.
Any time that is supposed to represent both a wall-clock time has to deal with it.
There is currently no known answer to the question "What is the interval between the unix time stamps @1720026000 and @182002600" However, there is a well defined answer to "What is the UTC time for @182002600" and thus also "what is the local time in a timezone with UTC offset X for @182002600"
If we were to redefine Unix time to use Atomic Time, then we could answer the first question but not the second.
> We add an entire day to the calendar about every 4 years. It's not a problem because everyone is aware of it. So I think the only real thing that needs to change about leap seconds is awareness of them.
It's not just "about every 4 years" it's precisely "every 4 years, except for centuries, except for quad-centuries." If you give me any year, I can tell you if it will be a leap year. I can program a non-internet connected device and it will get leap years right indefinitely. Leap seconds are not predictable, but rather determined empirically and announced about 6 months ahead of time. Any device that wants to properly account for them needs to be updated at least every 6 months to be correct.
Specifically when is not knowing UTC will skip a second six months later a problem for you? As I said, you don't know the interval between any two seconds on your clock, a sync or frequency change can happen at any time. And if you really needed to know the interval at those points, Atomic Time can serve your purpose.
Leap seconds are a problem because I have to deal with existing systems that use leap seconds and those that do not. Getting those systems in sync can be pain sometimes because of conversion from one format to another. Is it insurmountable? No. Is it annoying? Yes. Does it occasionally cause bugs that waste time and resources? Absolutely.
I'd love to snap my fingers and make everyone use TAI, but unfortunately I'm stuck with UTC, GPS and TAI depending on sources.
Why are you trying to sync systems that use leap seconds and ones that don't? It sounds like you've invented your own time system.
Time aligning GPS data with other sensors/systems that record in UTC. I'm combining data from multiple different sources together that I do not control. The duration of the data is long enough that an occasional leap second slips in and offsets things.
So, you just need to set up a scheduled task to download the leap seconds file from the IERS once every six months?
> Leap seconds are needed in civil time because people's schedules are still dominated by the Sun. Not to the second, maybe not even to the hour.
Sometimes multiple hours off. China has a single time zone.
As far as I can tell, people care very little about the clocks being in sync with the sun. We've effectively run massive experiments demonstrating this.
What experiments are those? I don't doubt if you lock someone in a room they'll lose sync with the sun, but people in society do rely on it. The fact that we use DST in the face of very vocal opposition shows a lot of people do care about it.
The existence of China as an outlier isn't much evidence. The most people on one side do not keep the same schedule as those on the other. If daylight really weren't an issue, there would be only one timezone for the entire Earth. So you can't point to one while ignoring the reason all of the others exist.
Yes if you use atomic time you won’t encounter these issues.
Unixtime made a blunder of incorporating the leap seconds all those years ago so it’s not atomic hence the issue.
Now you might think it’s crazy that Unix time incorporated non-atomic leap seconds when it doesn’t incorporate any other part of the local sun relative position in its counter and you’d be 100% right in that. Leap seconds absolutely belong in the local time printing functions and nowhere else. But the blunder was made and now computers by default don’t have atomic time and here we are.
Or we could adopt the "smearing" technique in either direction and we could do it hourly or daily or weekly or monthly or half-yearly or whatever interval as agreed.
Maybe we should do it every 6 months no matter what. That way, everyone would know that on June 30 and December 31, there would be smeared seconds.
That makes the "do it rarely and people will screw it up" problem go away.
Just make leap seconds first class.
https://gavinhoward.com/2023/02/make-the-leap-second-first-c...
If I am asking for how many seconds since 1970, I'm literally asking for that, as if someone stood with a stopwatch (not a cellphone clock!) How you want to display that in various timezones i do not care
You speak of time as if it's some directly measurable quantity. Instead, all we have are periodic quantities of various (messy) physical processes or sampling methods thereof relative to certain underlying models:
- _TAI_: Sampled average of ticks in the (very noninertial) frame of the surface an implicitly-defined idealized rigid Earth. Each tick is further a sampled approximation of our definition of a second, which invokes idealizations at absolute zero.
- _UT1_: Mostly the same frame as TAI. Each tick is considered a sample, trying to measure the "true rotation" of some idealized rigid Earth, module any geophysics. Note, the definition invokes quite sophisticated models of celestial mechanics, and explicitly ignores certain kinds of "high frequency perturbations".
- _UTC_: Based on UT1, but take into account some basic, empirically-measured geophysical processes.
Depending on the particular physical processes, models, and sampling methods you choose, the quantity you get for "seconds since 1970" will be different, and there will be (complicated) relationships for how each of those processes transform tick counts between each other. In some cases, the transformations will be a priori impossible, only permitting approximations under simplifying assumptions.
IMO, the remarkable thing is that the various ticks all line up as well as they do, which is why we can mostly get away with treating all these as a single unified Ticking Time concept. On the other hand, I also think the various standards do a reasonable job delineating messy reality into potentially useful tick-producing processes and the systems needed to make those practically useful.
As a software engineer, the lesson for me is that I can't always ask "what time is it?", "how long has it been?", or "which came first?" Instead, we I may need to shift focus onto different invariants in the problem I'm trying to solve.
> As a software engineer, the lesson for me is that I can't always ask "what time is it?", "how long has it been?", or "which came first?"
If we were using TAI instead of UTC we very easily could.
Really? TAI cannot locate historical dates indefinitely. TAI doesn't even make sense on timescales that exceed Earth's lifetime. It doesn't encode enough information to answer questions about elapsed time of even ideal clocks at real, physical locations to arbitrary precision. Fast enough operations on a distributed database can exceed the precision limits of TAI's definition, making it impossible to canonically order events.
> Fast enough operations on a distributed database can exceed the precision limits of TAI's definition, making it impossible to canonically order events.
The TAI would be a sincronization target, just like UTC. Any device can have its own high precision clock and periodically sinchronize with other clocks (just like NTP does) which to my knowledge is how most distributed systems work
> TAI doesn't even make sense on timescales that exceed Earth's lifetime
I disagree, 10^100 seconds in the future is perfectly valid time in any time system
> It doesn't encode enough information to answer questions about elapsed time of even ideal clocks at real, physical locations to arbitrary precision.
Those clocks would use the TAI to avoid drifting from each other.
> I disagree, 10^100 seconds in the future is perfectly valid time in any time system
Professor Einstein would like a word...
> You speak of time as if it's some directly measurable quantity.
They do not.
> Depending on the particular physical processes
They have chosen their particular physical process: "as if someone stood with a stopwatch"
> They have chosen their particular physical process: "as if someone stood with a stopwatch"
It's not well-enough defined for all purposes.
Where is that person standing? Earth's surface is shifting and moving all over the place willy-nilly, so how do you define that particular location in the first place? Over what timescales is that definition valid? What physical process do you mean by stopwatch? What particular synchronization protocols do you define? What physical models do your definitions invoke?
Answers to these kind of questions will generally generate mutually-disagreeing time standards. I mean, with suitable transformation rules, they'll often agree up to some precision limit, but if you need anything beyond that, you've now gotta choose the one(s) that best correlate with the natural ticks in your problem domain.
Also, any standard like "someone standing with a stopwatch" is forced to just a fiat declare the stopwatch as the Definition of Time, a la the platinum sphere kilogram. We all know how great that was. Do you now want a team of canonical stopwatches and some aggregation process? How do you deal with measurable drift between the tick rates?
UTC doesn't stop us from having that, UTC seconds tick at SI rate. The thing that makes UTC special is that minutes might have 59-61 seconds each. But if you have stopwatch just counting seconds then leap seconds do not make any difference at all, and UTC and TAI are effectively the same.
UTC and TAI are offset by a variable number of seconds
Which doesn't impact a stopwatch in any way.
It does if the stopwatch is sinchronizing to prevent drifting, like most clocks do.
Then why does unix time not include the leap seconds?
Because POSIX committee thought it would make things easier for userland. It didn't; it did make things harder, much harder, for userland and everything else.
People make mistakes.
Ahh, so if I used an old unix mainframe, it'd count leap seconds differently?
Which specific stopwatch?
Why don't you care about that stopwatch's drift over the past 50 years, the tempreture related variation, the errors induced by motion, air pressure and humidity?
Would you prefer a count that's averaged over many from the same manufacturer, or from many over many manufacturers?
A cesium stopwatch: https://en.wikipedia.org/wiki/Caesium_standard
How deep in a gravity well are you planning to keep this cesium stopwatch?
Exactly at the point of Null Island at the epoch, of course. Or, in practice, as close an approximation as can be calculated by now.
Fun reference, although in that spirit it appears that Null Island at mean sea level for that point might be as much as 22m vertical separation from true 1G Geoid.
https://en.wikipedia.org/wiki/Geoid#/media/File:Geoid_undula...
Approximations are pretty easy until you get into the details, dammit.
Not at all what was asked for; not available as a handheld stopwatch someone could stand with in 1970 ... and I'm doubtful there's such a thing available today.
Works if you don't mind a lab bench full of equipment, but doesn't appear to match the specification of the request.
Still, thanks for your input.
Handheld was never specified directly, just “stood with a” which can just mean “next to.”
The HP 5061 was introduced in 1964, why do you think a counter that can reference the frequency standard is not possible?
You might want to be more rigorous about reading specifications.
The HP 5061 is not a handheld stopwatch, at best it's a counter top luggable.
> why do you think a counter that can reference the frequency standard is not possible?
How on earth did you strawman my thinking to reach that bogus conclusion?
You might want to be more rigorous about reading comments and projecting.
Switch to TAI + fixed offset
I just don't give a damn whether solar time is a couple minutes off of calendar time.
Seconds should be seconds. Solar time is a human construct, it shouldn't affect computers.
The person I responded to was interested in 50 years of seconds from a stopwatch.
That's a mechanical device with multiple sources of error and a need to be wound regularly.
The questions I asked are about common sources of drift in mechanical watches and wether or not they cared enough to attempt to account for them.
You're conflating the term "stopwatch" with an all mechanical device. That wasn't even true at the time period specified-- the quartz movement had been created in the 1950s and the first quartz pocket watch had been introduced in the mid 1960s.
The issues you bring up are only relevant to a particular set of devices that can be used as timepieces that measure the amount of time that elapses between its activation and deactivation-- and are are all stopwatches.
What is so special about thailand's timezone?
TAI not as in thailand, but TAI as in temps atomique international: https://en.wikipedia.org/wiki/International_Atomic_Time
I just tried to get a time in the TAI timezone via my programming language and it doesn't exist. Not a very useful timezone.
You can wrap libtai in almost any language, and that's been done for the bigger ones. Which language are you using, and why is the conclusion not that the language is deficient?
Maybe it should be added to the OS instead of a library? Why would I use a library for a timezone?
Maybe that's a fun new OS feature. If somebody wants to try it, more power to them.
Answering your question more directly though, why would you want it in an OS? The OS primarily exists to mediate shared resources, and to a slightly lesser degree to sensibly wrap shared code everyone is definitely using (e.g., chrome and hacker news don't have to care about my LCD driver).
What exactly do you gain by baking TAI into the OS? You lose in update availability, OS install size, application-specific customizability, runtime performance of TAI function calls, .... You'd want to gain something for those costs.
> Why would I use a library for a timezone?
Most people do? Even libc localization isn't a part of the OS (and is fraught with issues; never use libc localization), and that's the most primitive timezone library most people use. Everything else is baked into their language runtime or a third-party like nodatime. TAI isn't special in that regard.
Time is very much a hardware concern (as is the time zone database an OS concern).
It's not a timezone.
Ah, that makes sense.
the TAI stopwatch, the earth surface is relativistally uniform enough that averaging good clocks gives a good enough clock for almost any practical purpose.
In that case I suppose you'll need to find yourself a universe with different physics from ours...
Negative leap seconds seem like they shouldn't be much of a problem. At least they don't involve repeating a second.
No queries came in during a whole second? Who cares?
Negative leap seconds will mean that there will be UNIX timestamp value that is invalid. What should systems do when they encounter such value? Generally UNIX time -> UTC conversion is considered to be infallible, negative leap changes that.
Normally, nothing. The invalid UNIX timestamp can still be converted to a (also invalid) UTC timestamp, without needing to know whether or not it is valid. However, when you want to convert to a SI timestamp (e.g. in order to add or subtract a number of SI seconds), then you do have to consider it; in this case it might be an error.
Similar things apply with a positive leap second, although in that case the result is not an error. However, for positive leap seconds, when you are converting a UTC time in parts, into the UNIX timestamp, there is an additional time 23:59:60 for some dates. This can still be converted, although if you have a separate field for nanoseconds (or other divisions of a second) in the original UTC timestamp, then you will have to either subtract one second from the subsecond divisions, or change :60 to :59 and add one second.
And, then again, you will also have to consider the leap second when dealing with SI seconds, whether they are positive or negative leap seconds. You will get the wrong answer if you fail to consider leap seconds either way (although in the case of negative leap seconds, there might not be a "right answer" in some cases).
But, even if you do not consider these things, the timestamps will not be off by more than one second in either direction; this is not normally a problem, although in some cases it might be (which are the cases when it will be important to deal with leap seconds properly).
Sure, in theory the string 20xx-12-31T23:59:59 should never be created. But if it is created, so what? A time span is off by a second, in the positive direction. Not good, but shrug. I'm not saying it's a good thing. At time recording it's like the computer froze for a second.
Compare this to the problem of there being a unix timestamp integer that refers to two different times, which is what naive positive leap second implementations resulted in. Real time spans being impossibly negative.
Positive leap seconds are orders of magnitude worse.
Unless you're writing time keeping software, negative leap seconds can be ignored and will be "just fine". And if you are writing time keeping or benchmarking software, then this is just another thing to not have a misconception about.
> Generally UNIX time -> UTC conversion is considered to be infallible
And generally there's two seconds between N and N+2.
Yeah I'm wondering about that too. I don't think it could possibly be worse than having times like "23:59:60" pop up anywhere and messing every parser or regex up. It would just be like "huh, nothing bad (or good) happened during 23:59:58 and 0:00 according to our logfiles"
So my assumption was that Unix timestamps were monotonically increasing and that for the case of leap seconds the conversion from timestamp to UTC would take those into account and for some seconds have 2 mappings. That would keep the ordering of events, it would break assumptions like a day is 86400 seconds.
But I guess they decided to keep that invariant, which makes negative leap seconds really hard. Maybe that’s a good trade off.
The Rust standard library, which provides an API for monotonic timestamps, used to contain this silly hack (with appropriately exasperated comment) because in practice so many platforms and CPUs (Linux, Windows, BSD, x86, x64, Arm) failed to provide monotonicity despite their own documentation: https://github.com/rust-lang/rust/blob/80184183ba0a53aa4f491...
// It seems that this just happens a lot in the wild.
// We're seeing panics across various platforms where consecutive calls
// to `Instant::now`, such as via the `elapsed` function, are panicking
// as they're going backwards. Placed here is a last-ditch effort to try
// to fix things up. We keep a global "latest now" instance which is
// returned instead of what the OS says if the OS goes backwards.
//
// To hopefully mitigate the impact of this, a few platforms are
// excluded as "these at least haven't gone backwards yet".
Why exclude any platforms, just in case they start going backwards for whatever reason?
They say right there, "To hopefully mitigate the impact of this".
Having a mutex right there in the hot path of Instant::now is not great for performance. You expect getting monotonic time to be very fast generally, and some code is written with that assumption (i.e. tracing code measuring spans).
Ah, that's fair. Didn't realize there was a significant performance impact.
Eventually Rust just gave up. Here you go, here's your "monotonically increasing clock" courtesy of your operating system. It might go backwards, try asking your vendor to "fix" that and see if they laugh at you or just ignore you.
Sometimes the OS is broken in a way Rust can fix, for example Rust's current std::sync::RwLock actually does what you wanted on Windows, the C++ std::shared_mutex doesn't. It's documented as working, but it doesn't because the OS is broken and the fix is just on their internal git "next release" branch, not in the Windows you or your customers are running.
But sometimes you're just out of luck. Some minority or older operating systems can't do std::fs::remove_dir_all correctly, so, too bad you get the platform behaviour. It's probably fine, unless it isn't, in which case you should use a real OS.
Unix keeps the 86400 seconds as an invariant, and ignores the IS size of a second. This should work just fine for negative leap seconds too, you just make your seconds shorter instead of longer.
Of course, it's a near certainty that it won't work just fine. But it should.
I think history has proven it to be absymally bad tradeoff. If UNIX time were just actually true seconds since epoch counter then I think lot of leap second related hand wringing could have been avoided
Almost nobody ever cares for UT1 except for astronomical observations (where you are also likely using a different calendar and using sidereal days) and we already have a perfectly working system for relating local times to each other and to UTC: timezones.
The only things we should care about are local time (both as in clock time and in sun-position time) and universal timestamps to coordinate between local times and to use as canonical representations; leap seconds are useless or damaging to both of these.
We already easily accept over 60 minutes of offset between clock time and sun-position time and I do not think that 3600 seconds can be ok but 3601 or 3599 cannot.
It is also perfectly easy for a country to change its timezones or to adapt a non-whole-hour timezone (multiple countries have 15 or 30 minutes offsets)
So my proposal is that the IERS never announces any leap anything ever again and in a few centuries some countries will shift their timezone by 15 or 30 minutes.
This will be much more easily compatible with all current systems (we can right now create the timezone CETP and CETM for central European time plus 15 and minus 15) and in 400 years each at they leisure Europe/Berlin will be equivalent to CETM* (and CESTM if have failed to remove DST).
No need to handle irregular minutes or hours, no fractional seconds offsets, no need to account for edge cases that are far too easy to ignore, just keep writing code that work with timezones (as you should already be doing) do not hardcode conversion between regional timezones (Europe/Berlin) and offsets (CET, CEST, CETM) as you should already be doing just updating your timezone tables (as you should already be doing as they change often).
Just store one of:
- UTC and timezone
- dateless time with/without timezone
- date with no time with/without timezone
And you are ok, already prepared for the next few centuries of no leap seconds.
* I don't know whether it would be CETM (that is +00:45) or CETP (+01:15).
The solution is obviously to have a leap second every half year, even when the difference with solar time is too small. Just alternative positive and negative leap seconds, and for additional fun, don't have a leap second when the difference with solar has shifted (in the right direction; it should be possible to keep the difference less than 1.5 second, probably much less). We could even do this every month, just to make sure there's enough testing opportunity.
Leap seconds are an extremely Earth-centric concept.
Sometimes I have wondered is there proper write up of how messy intragalactic or intergalactic communications and time keeping would be. With or without FTL communication... Relativistic effects could actually be significant. Not to mention different rotation rates, day lengths, month lengths and so on...
Leap seconds are comparatively simple problem...
They're considering creating a new time standard for the Moon. https://news.ycombinator.com/item?id=39916102
Yea, unfortunately, all of our really good telescopes are bolted to it.
JWST lives in the Earth-Sun L2 point, so I suppose that's still technically true.
If the IERS ever announces a negative leap second, they should do it like this:
https://m.youtube.com/watch?v=fr1li5NaltA
There is no mention of the affect this might have on investing or wagering.
Or is the author keeping that close to the vest?
They don’t care about that. I mean it’s the opening paragraph…
> I just want to see it. Just once. I want to watch that earthquake ripple through all of global electronic timekeeping. I want to see which organisations make it to January morning with nothing on fire.
Seems like a good dry run for redundancy/resiliency tests in the face of more catastrophic failures such as those that can result from solar storms.
I agree with the author in finding some amusement in such trivial (in context) matters falling in the face of a phenomenon as fundamental as the planet's spin, something humans will likely never make a dent in.
Don’t give them any ideas! If I know humans, they’re the kind of species to figure out how to extract energy from the Earth’s rotation, overdo it way too much, and then deny that they’re the ones responsible.
See also:
> Tidal Energy Is Not Renewable
> It is incorrect to consider tidal power as renewable energy. Harnessing tidal energy will pose more severe problems than using fossil fuels. ... Tides are induced by the rotation of the Earth with respect to the gravity of the Moon and Sun. The rotational energy of the Earth is naturally dissipated by tides slowly. Consuming tidal energy further reduces the rotational energy, accelerates the energy loss rate, and decelerates the rotation of the Earth.
https://cs.stanford.edu/people/zjl/pdf/tide.pdf
(I've not evaluated these claims in detail, I just thought you may be interested.)
It's completely wrong. He assumes energy will increase exponentially into the future to get to his wild claim that we could tidally lock to the moon in 1000 years. Even solar power out nuclear could not power humanity in that scenario
Certainly if we grow exponentially for a further 1000 years we'll exceed the carrying capacity of this planet, however we derive our energy. I don't think that's a very interesting result.
By "completely wrong" do you contend that using tidal energy doesn't decelerate the Earth's rotation?
Can we even change viscosity meaningfully?
(Coastlines already form natural "dams". All we would do is move the coastline inward a bit, so as the tide flows through it it spins turbines. The water gets moved the same. The energy is already dissipated at the coasts, it would happen at the dams. Total dissipated energy is the same this way. Okay, if we start putting 4 km tall dams in the middle of the ocean we might somehow meaningfully change the viscosity.)
The thesis in the PDF seems to be that somehow we can push the brakes more. Maybe. (So if we let the Sun/Moon grab some water then use the Earth to get it moving again, then it necessarily slows down the rotation. But there's already a lot of energy in moving and compressing water itself, sure it's "uncompressible" compared to gases, but there's plenty of molecular stuff to move around where energy can go. There's some tidal heating too.)
It's verbose, but in a bad way, and it's structured in a way that makes it hard to comprehend. (And the whole pro-fossil-fuel framing is just .. huh.)
Imagine what a Dyson sphere is going to do to the lunar orbit around Earth.
[dead]
You need more than a negative leap second to get anytime close to Christmas, though.
Always facinated by how complex standardizing timekeeping is. If here was a chance for a global redo, would there be a more simplified system?
Almost certainly not.
The problem time keeping is meant to solve is coordination of physical movements between separated parties that have exceptionally limited and delayed communication capabilities.
All of the time issues we deal with today are in service of keeping these important properties of our civil time in tact.
In terms of computers we should happily ignore the problems of civil time, simply just use TAI, and use a provided database to convert this into "human display time" whenever necessary.
Leap seconds do absolutely nothing to fix the problems you’re talking about, for anyone. If we had never invented UTC and used TAI (+ time zone offsets) for civil time, the fact that civil time is drifting away from solar time on the order of a minute a century or so would at most be an obscure curiosity.
The question was about historical time keeping in general, not about leap seconds specifically, so I'm not sure what point you're trying to make here.
Also, astronomers care about leap seconds, and astronomy is an important tool in making observations which lead to predictions about our universe, so I wouldn't be so cavalier in labeling it an "obscure curiosity."
I'm pretty sure astronomers don't care about leap seconds, and use more precise/fit-for-purpose tools.
The whole reason to have leap seconds is _because of astronomy_. If we removed the leap second from civil time keeping, astronomers would still maintain it, because they want their observations across several decades or even centuries to use a time scale that's linked to the rotation of the earth.
That's because their telescopes are bolted to earth. So when the rotation rate changes the time at which certain features appear in the telescope also change.
They might consider using a higher precision version and make smaller updates more often but since the rate is not perfectly predictable and can be altered by local events on earth and you want all astronomers on earth to agree to the current value the second is the most reasonable unit of change for them to use.
Ok fair. If it is so important to astronomers they should maintain it themselves rather than forcing the rest of the world to.
[dead]
On leap minutes:
> Because there's nothing computer programmers handle better than special cases which only occur every hundred years or so. How in the world could this be an improvement?
If it's less than 60 times as disruptive, it's an improvement.
> everybody's going to hate it at least sixty times as much as they hate leap seconds now
I doubt that.
> If something is difficult, you do it more often.
It has to be more often than leap seconds to really get those gears oiled. Unless this is a proposal to do leap deciseconds, I don't think this method reduces the pain.
> But before 1972 UTC and TAI were kept in much closer synchronisation [...] (No, I'm not advocating returning to this state of affairs.)
Coward! But seriously, I think this hurts the previous argument significantly.
I'd push for making it an hour already.
If synchronizing our clocks with the Sun is still important by then, then announce it a decade or two beforehand, and make a large ceremony out of the thing.
You don’t need to announce it a decade in advance. Time zones change all the time, we already know how to handle it and it requires no global coordination. Some country announces that part of its territory is changing time zone, the tzdb is updated, and everything continues working fine for everyone. This happens a few times a year already.
Sometimes on quite short notice too. https://codeofmatt.com/on-the-timing-of-time-zone-changes
The obvious disconnect is the digital bits inside my hardware clock shouldn't need to care about any of this. Then you can change it as often or as little as you like.
I assume you mean high precision clocks in computers because an actual clock won't care about half a second.
You could use TAI-ish timestamps right now, but people are going to get confused and make mistakes if your timestamps are almost UTC but several seconds off. And if UTC stays constant then you need to nudge all the time zones around and that sounds even worse.
So, you can build complex algorithms to smear leap seconds into clocks at random intervals, or you can use a published database to adjust TAI time to human time.
I think the later is less fraught with problems and doesn't require software changes in order to realize updates.
You're going to have to deal with the offset one way or another. I'm simply suggesting a means to keep the offset but not have to worry about how to realize that in terms of complicated hardware hacks.
> So, you can build complex algorithms to smear leap seconds into clocks at random intervals, or you can use a published database to adjust TAI time to human time.
That's a choice we have right now, today, and as far as I'm aware nobody chooses TAI for their systems. I think that says a lot.
> You're going to have to deal with the offset one way or another.
Most things don't really care. Oh the clock's off by 1.7 seconds, let's make an adjustment and check again tomorrow. Leap seconds are below the noise floor.
> It has to be more often than leap seconds to really get those gears oiled. Unless this is a proposal to do leap deciseconds, I don't think this method reduces the pain.
Yeah, if we're not going to abolish leap everything in UTC completely (which I think we should) then leaps need to happen at most quarterly. When the last leap second came through it was long enough since the one before that the bugs in Linux had been fixed and then unfixed.
Do we introduce an unnecessary leap second and then negative leap second every year just to keep the gears oiled? And then if we need one for reals we can increase it to two leap seconds added and only one removed. Though of course that will cause bugs in any code that isn't expecting two leap seconds to be added and assumed that there would only ever be one. sigh
Just accept that time will very slowly drift over the period of many centuries. It's really not a big deal. It's a complete non-problem that doesn't need any solving. Especially since coming up with a robust scheme that will work over the period of many centuries is quite hard (the current leap second system doesn't suffice).
> It's really not a big deal.
Unless, of course, you are a satellite.
I don't know what you're referring to, but as far as I know satellites can work perfectly fine without a leap second. I'm not aware of any practical advantage of leap seconds anywhere. The only difficulty in abolishing the leap second is that some systems have it incorporated in their protocol, but that's a protocol issue and not an intrinsic time drift issue.
Time is attached to the orbit of the earth (very precisely) so when time goes out of sync of the earth, it won't be a good day for anyone.
Most satellite systems don't use leap seconds; you don't need leap seconds to have satellites. And leap seconds don't really "sync time with the earth"; that's not how any of this works. Whether it's now 13:04:00 or 13:04:27 is somewhat arbitrary and all leap seconds do is maintain a certain arbitrary definition.
Orbiting around earth is going to be based on sidereal time, which drifts 4 minutes per day.
Converting into normal units has no reason to care about leap seconds when it can use the actual offset and be a few orders of magnitude more precise.
We could build it into daylight savings time. Instead of jumping an hour, we announce what the jump will be every year.
Not everyone's jumps happen at the same time (or ever).
We already have non-integer timezone differences. We could allow for leap seconds in that. Europe's timezone could be UTC+2:00:01 while the UK is still UTC+00:00:00
It vaguely feels like it ought to happen yearly. Yearly, but no option of a shift of exactly zero, so everybody knows it is coming every year no matter what.
I had to recreate an account just to reply to this discussion because I'm so appalled by its content. At the time of me writing this, 99% of the comment here are complaining about UTC moving to keep track of solar time or smugly arguing that we shouldn't do that.
Different time standards exist. International Atomic Time (TAI) is a strictly monotic clock based on the average of multiple atomic clocks throughout the world. UTC is defined as a tweaking of TAI to approximate UT1, a rough definition of which would be the historic mean solar time at longitude 0. UTC shifts TAI to be within one second of UT1. That's both its definition and the whole point of it even exising. I repeat, it UTC didn't track solar time, it would have no reason whatsoever to even exist.
If you want TAI, just use that. Stop complaining that UTC is not it.
I don't understand that someone just want chaos. I guess "Some people just want to watch the world burn".
But negative leap second shouldn't be so noticeable since it will just be a jump from 31 dec 23:58 to 1 jan 00:00.
Facebook made a lot of FUD about a negative leap second but I don't think it should be THAT a concern.
[dead]