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.
There's the astronomical applications, where a second error corresponds to a couple of arcseconds of precision, which is just a bit better than most applications want.
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.
