IMO the best argument for time zones is it keeps calendar days roughly[1] aligned with “natural” days, such that day changes happen when it’s dark outside and most people[2] are asleep and most people won’t be entering a new day during a work meeting.
Why? Because it is confusing if most people’s natural days are divided into different calendar days. If I wake up and the calendar says Tuesday, then I can be sure that I don’t need to worry about the dental appointment on Wednesday afternoon. But if Wednesday starts midday, then I have to spend extra brain cycles to work out which parts of my natural day belong to Tuesday and which parts are Wednesday. It’s a lot of hassle avoided by having days change over when I’m asleep.
If you want real life example of such confusions, look up “early morning flight confusion” on your favourite search engine. It turns out a lot of people are confused by flight times like “Wednesday 1:20am”, because if you are catching an 1:20am flight, you are heading to the airport on the previous day before midnight, and mentally the flight feels like a part of the previous “natural” day. What sometimes happens is people will book a flight on Wednesday 1:20am, head to the airport on Wednesday evening because they think “well the flight is on Wednesday right”, and find out that it is actually Thursday after midnight.
By the way, one successful attempt at addressing this problem is Japanese late night anime schedules. If an anime is aired on Wednesday 1:20am, the TV station will instead write “Tuesday 25:20” on the schedule. It makes no sense from a technical point of view, but feels right for the human because what is the early morning of Wednesday if not just Tuesday night prolonged?
[1] Even extreme cases like Spain are only a couple of hours out of sync, it’s not like the sun shines on Madrid during “midnight”.
[2] the article mentions remote workers and frequent travelers, which I am willing to wager are a tiny (but over represented in nerd spaces) fraction of the society.
Incidentally, this works for someone close to the UTC time (3h off for Moscow) for the reasons you mention.
It likely does not generalize at all.
They also haven't faced an issue where an event is booked by someone else at a DST-affecting time: as that time changes between two days, you now need an extra "if" in your brain (is it DST there? Europe and US are on different cycles there too).
I've tried booking all the cross-timezone meetings in UTC, but didn't get far with it: it was more work for everyone compared to somewhat reduced confusion and suddenly overlapping meetings.
> It turns out a lot of people are confused by flight times like “Wednesday 1:20am”, because if you are catching an 1:20am flight, you are heading to the airport on the previous day before midnight […]
If you use 24-hour ("military") time—00:00 to 23:59—this becomes less confusing. Perhaps an attempt to culturally shift from using 12-hour to using 24-hour time would be useful. (In the US it'd probably less of a challenge than metrification.)
[1] https://en.wikipedia.org/wiki/Date_and_time_representation_b...
[2] https://en.wikipedia.org/wiki/12-hour_clock#Use_by_country
Maybe it’s less confusing in practice but it’s not clear to me how in theory. It seems like the core issue is still present: an event so early in Wednesday’s morning feels like an extension of Tuesday night so one has to remember “Tuesday before I sleep” when the event details say “sometime Wednesday”.
Its possible your example is wrong and the confusion arises in the "twelves" (i.e. 1230 AM being 0:30 which makes no sense since anyone that didn't learn the quirk would expect the AM/PM bit to roll over at the same time as the hours, not one hour off the mark).
> because what is the early morning of Wednesday if not just Tuesday night prolonged?
This is what really grinds my gears with the official definition of "night" and "morning".
Tuesday 21:00-23:59 is considered "night", and then Wednesday 00:00 is considered "morning", which is highway insanity to me. No one would say they were going out 'till "Wednesday morning" if they went to the pub until 02:30 Wednesday.
IMO it only starts being "morning" around 05:00, maybe even 06:00.
Due to the tilt of the earth the length of a solar day is not constant (unless you're very near the equator along a specific, probably wobbly, line).
Even now, obtaining solar noon is comparatively easy. Then add half of an earth's rotation* (slightly affected by the earth's orbital period too), and that's midnight.
In the days of candle light, midnight wasn't a crazy time to draw that diving line. However these days even people with crazy early AM weekdays to avoid commutes sometimes cross over midnights on the weekend.
+
You are correct that the modern world really should just start counting the day at like 3 or 4 am, and continue counting past 2359 to almost 2700 or 2800.
Haha, don't get me wrong, I am not asking for official days to be anything but 24 hours.
I guess I am arguing that "morning" "midday" "evening" and "night" should hold no official definition, since they are much more about the vibe rather than an absolute position on the clock. However, if they do remain as official definitions, they should be heavily revised.
It's usually morning after you sleep.
"I woke up very early in the morning at 4am to start work at 5."
I like to say things like "13 in the morning" to say "1pm but I just woke up".
> one successful attempt at addressing this problem is Japanese late night anime schedules
Depending on the channel, the "new date cut-off" (more accurately: 日付変更) sometimes varies. Some channels start the day at 5am, others at 4am, and so on. Because of this, one gets to see wild things, such as a time-table scheduling a show at "29:30" whereas another channel would write "05:30".
In any case, your claim is correct. The people who stay up to watch late-night shows do not consider their day finished around those hours, and the times are intended to reflect that. However, there is still inconsistency around the hour of the new day.
A similar issue exists in video games. I know of one game that "starts the new day", so to speak, at 5am, and another game that does so at exactly 12am. To add further confusion, many Japanese websites and games are designed with the assumption that the user is always in Japanese Standard Time. (Most Japanese do not travel abroad, and Japan itself has exactly one time zone, thus Japanese programmers rarely ever think about time zones). Thus, when overseas, you may see the new day in a video game start at 1pm local time!
I believe all these problems are caused by time zones, not solved by them. If the current date/day of week wasn't vaguely connected to sleep/wake cycle, we wouldn't be conditioned to assume it was.
For instance, we handle 24 hour clock (with 60 minute hours?! WTF?) fine, even if it's insane and we use the decimal system elsewhere. Because we got used to it when we grew up. Many even have the clock reset in the middle of the day, ending up with things like two hour activities spanning from eleven to one! (Don't get me started on shit like "half four" - it means different things depending on where you are, but it never means two!)
Heck, there's a whole, huge country that gets by on inches and ounces and pounds and miles and whatnot - a mind boggling amount of extra mental energy required, and with the exception of some recent lapse when selecting their boss dude they seem to be doing mostly as well as (and over the previous century arguably somewhat better than) the rest of us in the thinking department.
If we grew up with date/day changing in the afternoon, every kid in preschool would have it figured out already. "Early morning flight confusion" would seize to exist (except, perhaps, for the poor bastards who'd happen to live close to wherever we decided to place the prime meridian), because everybody would know what "1:20" meant, and not randomly guess at something based on when they happen to sleep.
Yes and no, locally it would work because that's what you grew up with, but traveling, and especially communicating would be equally confusing. Currently we have that problem on globe-spanning video calls where "let's schedule another meeting tomorrow" could mean very different things. In the global utc scenario, tomorrow would still mean different things to someone growing up with "midnight" during the day vs. When you're asleep.
Again, I believe the problem you're talking about is caused by time zones.
If you're used to date changes happening "whenever", you'd stop assuming they happen at a fixed point during the day.
Any argument that starts with "Today, we're already confused about ... because we're used to date changes occurring while we sleep" is meaningless, since we wouldn't be used to date changes occurring while we sleep.
The whole terminology thing would be solved by having two words; one meaning "after next sleep cycle" (which would probably be more common when speaking to people in your own geographic region), and one meaning "after next date change" (which would probably be more common when speaking to people in other geographic regions). The appearance of this second word would likely happen naturally within weeks, if not days after abolishing time zones. As usually happens with language.
The argument against abolishing time zones always seems to assume that humanity would be incapable of adapting to a time zone free world. Like this would mysteriously be the first and only change in the history of mankind society couldn't adapt to.
> If you're used to date changes happening "whenever", you'd stop assuming they happen at a fixed point during the day.
But that's not the case. We're not all cosmopolitans traveling the world all the time. For anyone living in a timezone where 00:00 happens when most people are asleep, there'd only be one word for tomorrow, as it'd be synonymous for "after date change" and "after the next sleep cycle". There would be no other word, because there is no need for that. Except in circles where coordinating meetings with people across the globe happens on a regular basis. But we already got that figured out by explicitly naming the time zone or using UTC.
The vast majority of people don't have to deal with this, so having the date change at night is just more convenient, as it completely avoids this ambiguity in day to day life.
But obviously as a nerd you get hung up on that one aspect and go "but imagine we had only one timezone, we could just say 13:00 and there'd be no ambiguity, no chance for a misunderstanding, it would be so much more efficient and coherent!"
> The argument against abolishing time zones always seems to assume that humanity would be incapable of adapting to a time zone free world.
Again, you need to take a step back and try to look at this from the average person's pov, not as a scientist trying to find the optimal solution for a problem 99% of people don't have. And "people would be able to adapt to this" Is a pretty weak argument. You could probably also change the clock itself so that there's 63 seconds in a minute, 59 minutes in an hour, and 195 hours in a day. I'm sure people could adapt to this. Doesn't make it a good argument.
On the other hand, just imagine the sheer chaos this switchover would cause worldwide, for what, marginal gains in convenience for a miniscule amount of people.
It reminds me of "that guy" who constantly wants to refactor half the codebase because something would look a little cleaner then, and if you let them, they'll end up refactoring the same part of the code over and over again every six months because they had another idea how to make it even more streamlined and elegant. And then someone else comes in wanting to implement a simple feature, but is greeted with an incomprehensible construct, while the refactoring-guy is repeatedly and excitedly reassuring them that it's "really simple and intuitive once you get the hang of it".
> But that's not the case. We're not all cosmopolitans traveling the world all the time. For anyone living in a timezone where 00:00 happens when most people are asleep, there'd only be one word for tomorrow, as it'd be synonymous for "after date change" and "after the next sleep cycle". There would be no other word, because there is no need for that.
Meanwhile, I know what the word desert means, even if I have never been in a country that has one. I know what a cyclone is, even if I've never seen one. We're affected by, and have knowledge of more than our local environment. We read books. We watch TV and movies. Heck, we're having this discussion in a language that that isn't spoken in the country I'm living in. Most people do, in fact, interact in some way with people in other time zones right now. Perhaps not on a daily basis, but at least a bit.
It just occurred to me; if we placed the meridian in the Pacific, very few people would have the date change during their sleep cycle. Sucks to be Niue, I suppose ;)
By the way - I'm not even for abolishing time zones. I'm just spectacularly tired of the straw man arguments against it. It's like saying "we couldn't build a city that's on both sides of the river, because people would drown when they go to work", as if building a bridge would be an impossibility.
There is a perfectly good argument against it btw, which is the one you propose at the end. The change itself wouldn't really be worth it. But that's simply because people are confused by changes. Not because the end result would be worse.
In that particular case, "another meeting tomorrow", I think my expectation is pretty much not affected by time zones. I expect it to be 24 hours from when the current meeting started, plus or minus 2-4 hours.
i mentally translate tomorrow in a business meeting usually means sometime in the next 8-40 hours...
You argue that any system would be easier if we had all learned it in preschool, then turn around and claim some massive, mind boggling amount of effort that must be expended by Americans to use ounces, miles, and all sort of other yucky units you might need a lot of energy to use, but Americans have been learning, alongside SI, since preschool. Just like how you don’t likely struggle with 7 day weeks of 24 hour days with 60 minute hours.
So which is it?
I don't find your argument to be coherent.
I don't get the flight example? Wednesday 1:20 AM = Thursday 1:20 (24 hr notation)?
Anyway it seems to me this whole problem arises with 12 hour notation.
I switched permanently to 24hr notation after my buddy asked me to pick him up from the airport at "one-o'clock on Thursday". No problem, I didn't have any classes Thursday afternoon, so "see you then". You see where this is going? At 0-dark-thirty I get a call: "dude, where are you?" Yeah. I still give him shit about it, thirty years later.
24hr time, folks. 24hr time.
Wednesday 1:20 AM (12 hr notation) = Wednesday 1:20 (24 hr notation), or is there another convention I’ve never heard of? Either way, this seems to further validate the original confusion.
> book a flight on Wednesday 1:20am, head to the airport on Wednesday evening because they think “well the flight is on Wednesday right”, and find out that it is actually Thursday after midnight.
This bit here, I don't understand what Thursday is supposed to do here. If my flight leaves Wednesday at 1:20 AM, I'm leaving for the airport Tuesday evening.
But if I'm interpreting OP correctly, people are booking flights for Wednesday 1:20 AM but leaving for the airport Wednesday evening? Why would you be confused about that?
You don't see why people would confuse "Wednesday in the middle of the night" with "Wednesday night"?
People do it all the time
[flagged]
The correct 24h notation would be: Wednesday 01:20.
By the way, if you’re used to 12h time, you can get a similar experience to that described in the article simply by setting your watch/phone to 24h time. After a while your brain just starts to recognize 15:00 and 3pm as the same thing, and there’s no explicit conversion required for you.
Wednesday 01:20 doesn't really help. They weren't accidentally showing up in the afternoon. The passenger knows it's the middle of the night.
Tuesday 25:20 has a much better chance of helping.
If we’re not accustomed to this “overflow” notation, it only looks like a typo and an error. In my world, the day-of-week begins/cycles at 00:00, so don’t tell me that is happening on a Tuesday!
It also does not help for entry into a programmatic form or database field. That sort of notation is only good for output to a human who knows this custom.
That's why I said chance of helping.
But the important part is that 01:20 does not solve the problem.
Well, I'm interested to know how you define "the problem" then, and what "solving" it would look like, and why that "solution" can be approached by unfamiliar notation.
The problem is that 01:20 on Wednesday is on Tuesday night, which trips people up.
There is no perfect solution, so I can't tell you what solving it would look like. But I'd say that putting "(Tuesday night)" next to where it says "01:20 Wednesday" would be helpful to many of the people making this mistake.
How would you define the problem? It's not people mixing up 1:20am and 1:20pm.
> 01:20 on Wednesday is on Tuesday night
But that's subjective. Even my grandmother in the early-80s said differently. Everyone's computer-time and our smartphones and our digital clocks we've plugged into the wall, all have switched over to Wednesday at 00:00:00 midnight.
If you go to a bar they will tell you, "last call is at two in the morning." If someone heard a noise they say "I woke up at three in the morning to look around." My mother called them "the wee hours".
Sure, colloquially, 01:20 is very late on Tuesday night, because the Sun hasn't returned to announce Wednesday, and the cock hasn't crowed. So that is another way of looking at it. Time is analog, the orbits of Earth and Moon are analog, and we're cramming them into digital approximations and binary categories.
But you've misidentified the problem. The problem is that different humans interpret differently. The interpretation is influenced by culture and language. My scientific culture says that 01:20 is on Wednesday morning, and that is in agreement with my dearly departed grandmother, my smartphone, my calendars on Google and Outlook, and honestly there is no outlier in my life, except you, and Crunchyroll(?) who would insist that "01:20 is actually 25:20 on Tuesday night", and that writing it in this way would "help" solve a problem, because we're just explaining how damned confusing that is to rational Americans or users of either 12- or 24-hour clocks.
So "the problem" in my book is that a hypothetical human looked at our hypothetical "01:20 Wednesday" as rendered by a hypothetical computer, and that human wasn't thinking like a computer, or an American, or that human was Japanese, and that human erred with their interpretation of time notation. Now I don't have any idea of what time notation "01:20 Wednesday" would prompt a hypothetical trip to the airport 24 hours late, so it is not like this human was applying a different but correct interpretation to this problem.
Why don't we write "very early on Wednesday morning" or "before sunrise on Wednesday" or "just after midnight" (the latter is literally what "a.m." means...) and it won't look like another typo. Because if you write "1:20am on Wednesday is Tuesday night" then I'm going to call out a contradiction.
Computers can actually help with this, because if I've made a hypothetical calendar entry for my flight and I email the .ICS file to you, then the timezone and day-of-week is baked-in to that, so if everyone's settings are correct, bypass human interpretations. Many airlines have a way to email your itinerary directly to your friends. Just use the tools.
True, it is less of an issue with the 8,760 hour notation as people usually notice new day’s eve.
Using UTC for everything strikes me as attempting to apply thinking that's convenient for machines to humans.
In the vast majority of cases, the most salient property of a timestamp, for humans, is what point it occurred in the 24-hour day/night cycle (and, secondarily, where it occurred in the 7-day week cycle).
Local time is an approximation of exactly that 24-hour cycle; the local time anywhere is approximately the elapsed time since the last solar midnight in that location. (Yes, it's not perfect, because in some places local time has a persistent offset from solar time, or even one that changes twice a year, but it's close enough).
UTC is an approximation of the elapsed time since the last solar midnight in England. Most people don't live in England, so this just isn't relevant most of the time.
If we all used UTC, sure, people living in one place would get used to the new correspondence to solar time; someone who spends all their time in Arizona would quickly get used to the fact that they now eat dinner at 12:00 UTC instead of 7pm. But it would make traveling more tedious: you'd have to re-learn the mapping every new place you went. It'd also make communicating with people abroad more difficult. If someone tells you "I went to bed at 08:00 last night", you have to know that in New Zealand that means they're an early riser or were sick; in New York it means they had a wild party and in Poland it means they worked the night shift.
There are a few cases where having a shared absolute time reference is useful; for example, scheduling meetings with people in many different countries, but in those cases people tend to spontaneously settle on a time standard and it doesn't cause many problems in practice. And even in many of those cases, the local solar time is still relevant (you wouldn't want to schedule a meeting for someone around their solar midnight), so you have to have some way of expressing it anyway.
Right. The 7-day week cycle is also completely arbitrary, perhaps the most arbitrary of all time duration units, but having something of that nature has proven useful.
The 7-day week originated in ancient Mesopotamia, particularly Babylon, around the 3rd millennium BCE. It was tied to the observation of seven celestial bodies visible to the naked eye: the Sun, Moon, Mercury, Venus, Mars, Jupiter, and Saturn. Each day was associated with one of these "planets," a system later adopted and refined by other cultures.
The Babylonians passed this concept to the Jews, who formalized it in their religious practices, linking it to the biblical creation story in Genesis, where God created the world in six days and rested on the seventh, the Sabbath. This Jewish tradition influenced the structure of the week in the Western world.
The Romans also adopted the 7-day cycle by the 1st century CE, replacing their earlier 8-day market cycle (nundinae). They named the days after their gods, aligned with the celestial bodies: dies Solis (Sun), dies Lunae (Moon), dies Martis (Mars), dies Mercurii (Mercury), dies Iovis (Jupiter), dies Veneris (Venus), and dies Saturni (Saturn). These names persist in Romance languages (e.g., French: lundi for Moon, mardi for Mars).
The 7-day week spread through the Roman Empire and was cemented by Christianity, especially after Emperor Constantine made Sunday a day of rest in 321 CE. Other cultures, like the ancient Egyptians and early Chinese, had different cycles, but the 7-day week became dominant globally due to Western influence, trade, and colonization.
It’s not perfectly aligned with natural cycles—365.25 days in a year don’t divide evenly by 7—but its cultural and religious roots have made it a near-universal standard.
It is not just convention it seams also to be a somewhat natural unit for humans. Each time some try to change it, people get sick.
Is it natural, or have we just adapted to it? Maybe if we had always had 10-day weeks, we'd get sick if we switched to 7.
This cannot be right.
I've known multiple people in my life whose working shifts do not correspond to the seven-day week.
I know of no illness from which they suffer.
People get sick when it's changed. People get sick when it's unchanged.
No other primate cares a whit. No other animal cares a whit.
Citations would be very useful here, otherwise it sounds like another random thing from minds unknown.
What do the symptoms look like?
The symptoms could be connected to emptyer wallets, because on workdays people earn, on weekends people spend. It would take time and shifting of minds to adapt countrys economics to, for example, three day weekend.
> someone who spends all their time in Arizona would quickly get used to the fact that they now eat dinner at 12:00 UTC instead of 7pm. But it would make traveling more tedious: you'd have to re-learn the mapping every new place you went.
Following local times won't spare you from having to learn local culture anyway, such as Spanish dinner times ranging around 21-23.
That’s true, but you still have to know much less information. In most cultures, most people eat the main evening meal somewhere between 18h and 23h; Southern Europe tends later in that range than most places, whereas the US tends earlier. This is still a lot simpler than each longitude having its own unique offset that can range anywhere from -12 to 12.
If you visit Spain as a tourist and eat at 19:00 local time every day, you’ll be slightly out of sync with the locals but you aren’t going to cause any huge drama. If you never even learned the fact that Spanish people eat later, you’d still basically be fine. So knowing that cultural fact about Spain isn’t absolutely essential the way it would be to learn the offset of each place in a world without time zones.
Also, thanks to daylight savings, the current time in England is 1 hour off UTC, so for 6 months of the year it's not even a good estimate for that.
Not the solar time.
> As a programmer, I’ve always been annoyed by the concept of administrative time zones.
> Five years ago, I decided time zones should be abolished, and everyone should use one coordinated time.
I can't tell if your comment is intentionally ironic, as in you're saying we need to enforce your view on others that enforcing their view on others is bad.
If this person was vandalizing cultural treasures or something to pressure everyone to use UTC, then yes I agree his forced technocratic fix to a social issue is bad. Just writing about it and sharing an opinion is actually very constructive, even if you disagree with his take.
An opinion becomes something a little more deserving of criticism when it’s saying things like “it should be abolished and everyone should do what I say.”
This wasn’t phrased like “I prefer to use UTC time and here’s why I like it,” it’s more like if this guy becomes king of the world we’ll literally be forced to used UTC time.
This is why the person you replied to said:
> it would be great if we could figure out a way to prevent it, and teach that in schools. Too many people like this in the world today.
Too many people think that constructively sharing a personal opinion and sharing a desire to impose restrictions on others are of equal merit.
> An opinion becomes something a little more deserving of criticism when it’s saying things like “it should be abolished and everyone should do what I say.”
I must have missed that quote, I seem to be unable to find that text in the post.
> This wasn’t phrased like “I prefer to use UTC time and here’s why I like it,”
I don't know, it kind of seems like it was:
> Here’s Adam’s story of how living by UTC transformed his productivity, and why it might work for you, too.
and
> Give it a try, you might find it as liberating as I do.
They're making it sound awfully optional if their intent was to put you in jail if you didn't do it.
I’m not sure how you missed it. It’s right there in a parent comment in this thread:
“Five years ago, I decided time zones should be abolished, and everyone should use one coordinated time.”
That quote is also in the article.
> “Five years ago, I decided time zones should be abolished, and everyone should use one coordinated time.”
> “it should be abolished and everyone should do what I say.”
The original and the (mis)quote are not the same thing at all.
The latter is not intended to be a literal verbatim quote in the first place.
Sometimes people interpret the complexity of the world as something to be eliminated rather than confronted and managed.
Seems to me that standardizing the entire world on a single time is confronting and managing the complexity of the world.
The existing system is more inertial and political than practical.
"Noon is when the sun is at its zenith in your area" is significantly less useful in 2025 than being able to coordinate globally with ease. It's also just not true in many (most?) cases, as noted in the article, where places like China have a single timezone even though there is a 3-hour discrepancy in the sun's position from one side of China to the other.
Different parts of the world are at different times of day, that complexity doesn't disappear if you ignore it. The more distributed your team is, the more important this becomes. People keep saying timezones only exist because of inertia, but I do not buy it. There's definitely complexity caused by political boundaries that isn't inherent to the problem, but the primary reason timezones exist isn't inertia, it's that they continue to be relevant and useful. Because people continue to keep hours based on their local conditions. I'm skeptical that the juice is worth the squeeze as far as eliminating the small overhead caused by political boundaries.
3 hours is one thing, 12 hours is another (and "So you want to abolish timezones" notes that people in China commonly use lookup tables, creating implicit timezones).
When I coordinate across timezones, I say, "Hey does 9amPT/11amET work?" (Assuming those are the relevant timezones). I don't see the problem with that approach?
Let's say you abolish timezones. Okay. How do I know whether it's rude to call Uncle Steve in Melbourne? I'm going to consult some kind of table and implicitly reintroduce timezones, right?
Because timezones require conversion/coordination by either you or the other party every time.
Conversely learning when your Australian co-worker or uncle gets off work (in UTC) must only be done once.
e.g. You learn that Uncle Steve in Melbourne gets off work around 07:00 UTC. So a reasonable time to call him and chat about life is 08:00 UTC. You text him and say "hey, long time no chat, want to catch up at 08:00?". He doesn't have to look anything up because he is also using UTC (or whatever). He says "actually I have a dinner thing, what about 11:00 instead?". Know confusion can be created, because this is the same time frame of reference for you too.
Yep, you have to be explicit when coordinating across timezones. I never say "how about 11" in that context, I say "how about 11ET." If you want to do that by using UTC as a lingua franca and everyone does their own conversion, that makes a lot of sense. If you want to abolish timezones, that's just brushing the problem under the rug.
People keeping different hours in different locales is inherent complexity. This is the crux of it. If you want to abolish timezones, you need to explain why it isn't a problem that people keep different hours in different locales. If you can't, then it boils down to timezones being annoying. They are annoying, but that's not sufficient reason to eliminate them.
Couldn’t I just learn that Uncle Steve gets off work at 01:00 CST, by figuring out his offset from UTC and combining it with mine?
Your solution doesn’t change that I have to figure out some “how many hours different is Uncle Steve”, just that somehow I’ll magically figure that out without using the simple UTC offsets we use to denote those differences now. It just papers over them.
Both scenarios require learning, only one scenario requires constant back-and-forth conversion, which in turn introduces opportunities for mistakes and confusion.
Here is another example: I schedule a meeting with my co-worker in London. I say "how about 10am your time?" This is because I know he is X hours behind my timezone because I've learned that fact. He agrees and I show up an hour late because I forgot about DST and that he is only X-1 hours behind now.
If we both coordinated around UTC, he would've said "actually 11 is better for me" and I would've showed up an hour earlier.
People have been blowhards for as long as there have been people. Live and let live.
Maybe it manifests from "timezones are a difficult problem for my profession, lets get rid of them".
"I decided time zones should be abolished..."
It reads as tongue-in-cheek to me :)
Just right for the "Abolish everything" show https://nebula.tv/abolish
Pragmatism is the rejection of principles on principle.
Pragmatism is compromising lesser principles in service of higher principles.
> Here’s Adam’s story of how living by UTC transformed his productivity, and why it might work for you, too.
> Give it a try, you might find it as liberating as I do.
Did you miss these quotes, or are they also part of the absolutism? Here are some ways I read it, which seem like fair interpretations and also don't make the author stand out as being particularly dogmatic or authoritarian:
Considering the quotes I provided, it seems likely that the author may have been suggesting that we stop using timezones as a society in order to mitigate the only two downsides that they listed, since those downsides only exist as a result of society still using timezones while they as an individual stopped using them.
Another way to read it could be that the author made a statement they believe is probably true ("timezones should be abolished") but they were not fully convinced. To gain confidence, they decided to gather further information: "I began with myself...To my surprise, it was easy" and then ended with two downsides of their experiment, suggesting that they realize it may not be a perfect solution, at least right now.
A third way one could read it is to consider that the author didn't propose fines, jail-time, or any other specific penalties for continued use of timezones in their hypothetical world. Without enforcing a penalty, what does it even mean to "abolish" a timezone? In the context of the whole post, it seems to be more of a thought experiment imagining what could be if society as a whole switched, rather than a prescription of what must be.
The unwillingness to engage with the author's thought experiment strikes me as more dogmatic than anything the author wrote, but perhaps I am not fully considering other possible interpretations.
Eh, I think it's more a drive to simplify things that exist because of inertia/"that's how we always did it". Time zones are arbitrary and silly (sun is most likely not halfway at noon for most of the zone), daylight savings is even worse. Imperial units too, get rid of them.
Exactly. By GP's logic, time zones are absolutist, and every town could & should observe solar noon independently.
I think folks are averse to "world time" (for reasons, largely inertial), so maybe the baby step is try 1 timezone per country (like China's done for .. 75 years ?).
I'd even argue Local Time has only ~4 useful times: dawn, daytime, dusk, & nighttime. Where I grew up, the parks closed at dusk every day. Nobody complained
If I take a walk at 7:05:35 PM every day, it seems very precise but doesn't indicate whether I need sunglasses or a flashlight. It's meaningless precision, like 0.6235 slices of pizza. If I'm coordinating a walk with you, I might as well use UTC: it still won't tell light from dark, but at least nobody'll be waiting for an hour due to DST. It'd make more sense to schedule our walk at `1 hour before dusk`, or "just" settle for UTC, IMO.
> like China's done for .. 75 years
China did that for political reasons. The Republic of China used five, and Russia uses two timezones across those longitudes. Similarly, I also find it quite weird that France and Spain are in CET. France shifted when it was occupied in WWII, but maybe it's justified to remain in CET to reduce friction with the economies of its eastern neighbors. Whatever. Vive la weird. Countries do that to themselves.
A deviation of half an hour from noon is barely perceptible unless you use a sunclock. People can roughly estimate when the sun will set by just looking at local time and considering the current season. What throws a wrench in the works is daylight saving time. I fully agree that DST a huge annoyance and that its benefits were always rather situational.
> Time zones are arbitrary and silly (sun is most likely not halfway at noon for most of the zone)
So You Want To Abolish Time Zones - https://qntm.org/abolish
Just send him an email. Or politely ask him about his schedule and don't make assumptions about it, because I, for instance, can be awake at 5am a weekend and asleep at 9pm on a workday.
> sun is most likely not halfway at noon for most of the zone
Being able to express where you are in the 24-hour cycle is useful. That's what local time is: an approximation of the time since the last solar midnight.
To the extent that the approximation is poor, it's an argument for improving it (Spain for example should really set their clocks back an hour), not for getting rid of it entirely.
For the same reason I still like temperature in Fahrenheit, despite knowing that it is inferior in all contexts other than weather and most of the world doesn't use it. Around 100F is dangerously hot and 0F is dangerously cold.
Besides, Kelvin is the most true temperature scale, not Celsius.
Above 0C you have liquid water, below 0C you have ice
I find this considerably more useful than the Fahrenheit equivalent.
Imo the best system would've been Celsius with double the precision, e.g. water freezing still at 0ºC but water boiling at 200ºC.
That way you have the "human livable" range kinda between 0-100, which feels very intuitive. Anything above 100ºC becomes effectively unlivable. It also means that it is much easier to distinguish between certain "zones". e.g. saying "70s" or "80s" is easier and more clear than with celsius where you typically are staying within a sliding 10º range from day-to-day.
I agree this is an improvement, but you'd still have a bunch of negative number days in the populated northern and southern hemispheres, which Farenheit further improves upon.
Yes that is marginally better in Farenheit, but centering on the freezing point of water seems more useful overall. Then you'd also end up with the coldest spots on earth never being less than -200C and the hottest spots never being more than 200C which is nice symmetry.
> but centering on the freezing point of water seems more useful overall
But why? Knowing the freezing point of water (at sea level, mind you) is only rarely useful to me in daily life. I think the eutectic point of salt and water (that is, the lowest point at which it's possible to cause ice on the roads to melt by adding salt to them) is marginally more useful; this happens to be about -6F or about -21 C. Perhaps it's a bit more important for farmers who need to know whether their crops will freeze overnight, but as a lifelong city/suburbs dweller who knows next to nothing about agriculture I couldn't really say. At any rate, most people are not farmers.
I'm asking this somewhat rhetorically: I don't really care about Celsius vs. Fahrenheit. The pros and cons between the two are so vastly outweighed by the utility of having a global standard that I really wish the US would switch. I'm just pointing out that I don't think that one particular physical property of one particular substance makes for a very strong argument either way.
I think water freezing without salt is much more common than freezing with it. For example knowing the freezing point of water is useful for setting your fridge/freezer temperature.
This is exactly the system I would have designed!
in the temperate places most people live, the temperatures rarely drop below 0°F and rarely exceed 100°F and humans can sense a change of about 1°F so setting a thermostat in F is a simpler matter.
the 60's are warm in the sun and cool in the shade or breeze, the 70's are warm, the 80's are hot and the 90's are really hot, and over a hundred you're looking at death. The 50's you need a jacket, the 40's you need more jacket, the 30's are downright cold and you need an overcoat, and the 20's are frigid.
Celsius has approximately none of those properties. Celsius the 20's encompasses a vast change in comfort level.
As a celsius-user: you dont need more precision to judge how a temperature feels. The ranges you mention for Farenheit exist for Celsius as well. And if you need more precision you can use fractional numbers but I have rarely seen more precision in household thermometers than just rounding to 0.5 or the next whole number. I assure you that it is a completely usable scale.
To expand on your point: a difference of 0.5 degrees Celsius is almost exactly a difference of 1 degree Fahrenheit (really 0.9). So, indeed, a thermostat that can be set to half-degrees Celsius is roughly equally useful as one that can be set to full degrees Fahrenheit.
99% of the time that I communicate about temperature, it’s in relation to the weather. Fahrenheit optimizes for the right thing. “How does it feel on a scale of 0-100?” is the nr 1 thing I use temperature for, nothing else comes close.
https://xkcd.com/1982/ Had it entirely right.
- ex Celsius user
omg! i've never seen that xkcd before, but on my own I do think switching to metric doesn't have much payoff for the average person, and I buy all the same socks! It's awesome for folding, for losing them one at a time, etc.
Nope, no. I appreciate the experiment and I did do this myself for about 4 months when doing some intense cross-Atlantic business consulting traveling.
Unlike DST today, time zones do still have economic utility in the modern world since there are many more personal and industrial activities that exclusively happen during day or night in a single locale and far fewer that happen 24x7 and routinely traverse multiple locales.
Clearly everybody should use Swatch Internet Time, also known as “.beat”:
https://en.wikipedia.org/wiki/Swatch_Internet_Time
Nothing is more rad than checking the dot-beat on my translucent plastic watch while waiting for dial-up to connect so I can update my ICQ status to let my global friends know I’m listening to “Barbie Girl” from a 128k MP3 in WinAMP. Pre-emptive multitasking baby.
Could be worse. Mecca has the world's biggest clock dial.[1] Originally, it was to be set to solar time at Mecca, but that was just too confusing.
I like to think .beats might've caught on, if they were UTC-based instead of UTC+1, because Swatch is headquartered in Switzerland, and I think that little offset made it obviously tongue-in-cheek.
Since ICQ shut down, I have stayed in the right mood by using the uh-oh sound as my phone message alert for high-priority people.
Well that took me back.
For some reason no friends or family took me seriously when I brought it up at the time.
Nothing, nothing at all, is more abhorrent than someone willing to make a change only to leave more work for someone else to clean up!
Yes, one universal time zone, used universally! Bravo, finally, indeed.
But with metric time:
• 1 metric hour = day/25
• 1 metric time minute = day/1000 = hour/40 = 1 mday
• 1 metric time second = metric minute/1000 = 1 µday
And while we are at it, since this is all about rotation, lets fix that too:
• 1 metric rotation degree = rotation/100 = 1 centi-rotation
• 1 metric rotation minute = rotation/1000 = 1 milli-rotation
• 1 metric rotation second = metric degree minute/1000 = 1 µrot
Notation: instead of '°', metric degrees use a filled circle '•'.
Now we have conceptual correspondence between 1 minute of time and 1 minute rotation of the Earth.
If you know your metric longitude, you know the local time shift, and vice versa.
Finally, a metric "milette" distance is defined as 1/1000 of the Earths circumference, or ~40km. The Earth's surface moves 1 millete distance -> in 1 minute of time -> over 1 minute of rotation
Ok, open for suggestion period.
> If you know your metric longitude, you know the local time shift, and vice versa.
I've also thought that setting time using longitude could make sense. Especially since I and many people tell time, schedule meetings, etc using a device with a GPS. This article [0] makes an interesting point about the effect that time shift based on longitude would have on computers in the same data center.
> At the equator, the position directly underneath the mean Sun travels west at about 463 metres per second. That means a standard rack unit is about one millisecond wide. ... So, strictly speaking, continuous time zones mean that clocks on machines in different parts of the same data centre — neighbouring racks, even — will need to be set to different times, depending on the exact positions of those racks.
It concludes that you would have to choose a single reference point to represent the time of a machine and that:
> We might even consider applying this consistency across all machines in any given data centre. This would simplify tasks such as e.g. collating accurately timestamped log entries from multiple machines. We would ignore the real longitudes of the various machines and set all of their clocks to the same local time. The interior of the facility would become an area of uniform time; a "time zone", as it were.
I've only heard "metric time" refer to strictly powers-of-ten seconds (kiloseconds / megaseconds / ...), not your fractions of a day.
Have you seen the French revolutionary decimal time? It's closer to your proposal but with 10 hours/day instead of 25, for more consistency.
Why reinvent the second when it already independent of the time it takes earth to spin.
is a day spinning around 360 degrees or from highest point of the sun?
and the rotation speed isn't constant anyway...
This is a measuring system for practical time.
Usual adjustments and shims apply, to maintain absolute accuracy, with some days having slight non-standard lengths.
FWIW, most phones allow dual time display, and GMT watches would be extra helpful here as you can essentially track both at once, using either as your 'main.'
> After an eight-hour flight, if you went to bed at 21:00 yesterday, you’ll do the same today.
The problem is, depending on where you landed, 21:00 could be typical start of the workday, and you'd be showing up to an empty office.
> If you had a call at 13:00 yesterday, it’s still at 13:00 today
This part sounds nice, until DST comes along to sabotage you. For only being twice a year though, it's probably still a net gain, one I hadn't really considered for someone who travels a lot.
> most phones allow dual time display,
That's how I have conky setup on my desktop. "Year : Julian Day : HH:MM:SS" in both local and UTC. With a fixed width font and the two right above each other it's exceptionally useful. It makes looking at logs captured in UTC much easier to parse.
Time zones let you know if you're scheduling a meeting with someone in the middle of the night.
It also enables common culture. If someone says they got up at 5am for a flight then it is widely understood that that is pretty early for a typical person, without having to explain as much in words.
If someone says they didn't get home until late, you know they probably mean 9 to some small hour of the morning etc.
Yes! Whenever people say that we should have one timezone I always bring this up. Either you have to look up what time it is in another country or you have to look up what time of day it is. Either way you still have to look it up.
You may have already read it, but in case you haven’t, I think this post illustrates the challenges with a single timezone rather nicely: https://qntm.org/abolish
Who are these people who say we should have one timezone?
Every time time zones are discussed here, there is someone who thinks should abolish time zones and use UTC.
The author of the article we're commenting on, for example.
And it's an idea that I see come up not too rarely on any post about time subtleties (time zones, leap seconds, etc.)
If they happen to work the "average" schedule for their location, and you know what location they will be in at the time of the meeting, and you don't mess up the conversion.
But if you try to schedule a meeting with someone they will immediately know if the time is reasonable for them and let you know.
Plus I don't see how it actually makes a difference, you just look up "what are business hours for $city" rather than "what time is it in $city".
Somewhat, but it does so poorly.
If you're scheduling something with someone non-local to yourself, you need not only know their time zone, but you also need also consider their latitude/longitude and what time of year it is so you account for the potential use of daylight saving time and their current sunrise/sunset times.
For example: if you schedule something at 7PM - is that daytime or nighttime? Well, if it's the first of October, and the person is in Kansas City, the answer is daytime. However, if they're in Phoenix, the answer is nighttime. And here's the kicker: the fact that Kansas City uses daylight saving time is irrelevant, as it would still be mostly light out even if you used standard time due to its higher latitude.
In fairness, that's not what they're arguing for. They're advocating using UTC for yourself, and since no one else does that you'll inevitably get good at conversions to other time zones.
But... why? Out of boredom?
> In my head, these are equivalent, like two labels for the same moment. There’s no mental conversion, no extra cognitive load.
Well said. Ill use this when explaining to my north american friends how 17:00 is 5pm in my head without doing any math.
Yep, it's now a lookup table.
In 2021 there was a website thehtime.com. It had the best concept for dealing with timezones.
https://web.archive.org/web/20211022024626/https://thehtime....
It shouldn’t have used both L and I though, and probably also have dropped O, in favor of adding X and Y.
Using continious letters for addititives values is a good idea (F+3) can be predicted easily. Yet i agree that confusing « symbols » should be avoided. Forcing UPPERCASE formeront plus using a prefix (Z might be a good one)
ZA:03 ZB:23 ZL:55 ZI:12 ZO:08
would work greatly for me
Z can look like 2 in sloppy handwriting.
Oh, that's brilliant.
And if your language doesn’t use the Latin alphabet?
I like the concept of a global time that maps to local time, and while I am unconvinced that Latin letters are the best way to do that, I can’t think of a better way. It’s either letters of some sort, symbols, or names, and none of those sound good.
Living UTC would be awkward, however as someone who works with real world data sets, USE UTC FOR DATA! and also iso-8601 formatting. Everything else is a nightmare. Thank you for attending my ted talk.
UTC for data is perfect for events that have occurred. It has corner cases for planned future timing that require further thought and probably storing wall time + locale.
I can see that would be an issue. Fortunately I guess, I don't have to deal with future events (except in case where the date formatting is ambiguous and I guess wrong, resulting in events appearing to have occurred in the future).
My co-workers consistently stick with UTC, but they refuse to include the time zone in strings in their databases. Drives me crazy.
The TIMESTAMP WITH TIME ZONE data type doesn't include the time zone, which is hilarious to me.
Sad for me... https://www.postgresql.org/docs/current/datatype-datetime.ht...
Moments that are fixed in time: store the event in UTC and record the rest in a string.
A description of a moment should instead by stored in the application's normalized and preferred format, often a string.
Moments in the future are not fixed in time. Countries change their time zones, sometimes with little notice. In most cases, humans will keep the event at the same local time.
Correct, what you state is implicit in my meaning of a moment, rather than a specification for a potential moment.
Why does it matter for your normalized baseline to be UTC? Why not your local time and convert everything into that in your head. The reference time zone seems arbitrary and your primary residence's local time makes the most sense IMO.
Because it's "Universal". It becomes fairly easy to calculate time of an unknown city, instantly once you know the offset. One less mental calculation.
I don’t buy it at all. If you are that used to conversions, you probably remember the direct offsets by heart. I know I do for the three or four time zones I care about.
That said the whole conversion thing is not an immaterial burden unless you’re really up in the sky longer than walking on earth.
The whole point of UTC is to have a shared reference baseline to communicate with the world; however the author is obviously not concerned about that, I don’t think, as they have to do the conversion into the third party’s local time in their head if they want to have any friends, so that point is moot.
The nerve of this person to post this at 34:29 my time, right when I'm winding down.
Looks totally stupid in my opinion...
After an eight-hour flight, if you went to bed at 21:00 yesterday, you’ll do the same today.
You can complain and work on improving a tool that will covert badly, but for me it is kind of transparent with recent technology. Phone and watch update themselves automatically when you leave an airplane in a different time zone country and most tools look at your location to show you relevant time.
If you say that it will make it more convenient to work with people in other timezones, that's not even the case, because UTC will not tell you if a time is a good time or not regarding local time. So someone giving you his country/timezones is enough for you to select a right time.
Let's imagine I'm working with you that is located a quarter of the world away, how do I know in UTC what time is the work day morning proper time for a meeting? 11h UTC? 22h UTC? 4h UTC?
When dealing with anything across timezones the reality is you ARE dealing with 2 time contexts.
1) global time. i.e. UTC
2) local “sun” time. i.e. local timezone
When scheduling a meeting you are trying to find an intersection of global and local time that works.
It’s messy but also our physical reality. The conversion still needs to be done, just in the article the person is living in global time and having to convert to local time when needed. Vs living in local time and converting to another different local time.
> Five years ago, I decided time zones should be abolished, and everyone should use one coordinated time.
> Moscow time, my local context.
Ah, Russia, what would we do without you! Never change. https://gwern.net/note/note#russia
My favorite thing about UTC is that the abbreviation was chosen because it doesn't make sense in French or English[1], (I like CUT a little more than TUC, though both are pronounceable as one-syllable words... unlike you-tee-see).
1: https://en.wikipedia.org/wiki/Coordinated_Universal_Time#Ety...
> Once I mastered handling two time contexts, adding more was simple. I now juggle four: UTC, my local time, my team’s time zone, and another I occasionally work with. There’s no confusion, my brain seamlessly tracks them all.
I don't really follow. I thought the whole concept was not having to do exactly this. Or maybe I just don't understand, I don't know.
If I'm investigating something and am interrogating logs, I'll mentally switch time bases to UTC, after which I'm natively thinking in UTC until I decide to switch back. I also have no issues converting to the handful of timezones I use often.
I'll never understand why people would want to use UTC as their native time. But then I'm on the other end of the absolutist spectrum, "often" looking up my local solar time, and shaking my fist at the sky about the local administrative time being oh so off from the "real local time" (that being, said local solar time).
I think that if you want to use UTC, you should make it clear by adding "Z" (or "UTC") on the end of the numbers which tell you what time it is. This makes it more clearly, avoiding some of the confusion they mention in that article.
However, I think that local time should be used as well as UTC, for different purposes, but that the local time should just use solar time, rather than using time zones and DST.
You can’t have standard seconds with solar time though (or minutes or hours), unless you live at the equator [0]. So it will be interesting to calculate at what local time your CI build is expected to complete, or if you have enough time to watch that 120-minute movie before whatever the equivalent of 10 o’clock would be in solar time.
Or alternatively, each day would have to end at a different time, but then 12 o’clock wouldn’t be solar noon (or midnight).
[0] http://wordpress.mrreid.org/2014/10/19/rate-of-change-of-day...
Solar time doesn't involve different lengths of seconds. The length of day and all the pieces doesn't change. Local solar time is effectively time zone on longitude. It is mean solar time.
The downside of solar time is that 1 minute of time is 15 arc minutes which is roughly 17 mi east west. Which means need to deal with time zones in same metro area.
The railroads invented time zones because dealing with local solar time was a pain. Minute accuracy is needed for time tables. We might be able to do it with computers, but it would require knowing the location of everything.
When the minute accuracy is needed between different places, that is when UTC would be used. It is helpful for travel, and for many other purposes.
For local stuff that does not involve precise measurement of timing, you can use solar time (and you can use a sundial), and you can do by the sun light (even, in summer it is more light and in winter it is dark early, you can use that, e.g. to go outside when it is light and don't need to turn on light inside, and in night time is dark you can sleep), and by the moon light (less commonly, but sometimes it is also meaningful and useful).
Even for things that do use precise measurement of timing, UTC is not always appropriate; for some uses you will use TAI, or SI seconds instead of UTC seconds.
UTC seconds are the same as SI seconds. Or rather, there is no defined term "UTC second". You may be thinking of seconds-since-epoch counts that don’t include leap seconds, like in POSIX timestamps. That's not UTC though. UTC is a naming scheme for points in time, not a prescription for how to count seconds.
What's true is that the exact number of seconds between future UTC times isn't known, because leap seconds aren't known arbitrarily in advance. But that doesn’t usually affect measurements of time. It does affect adding (large) SI-second counts to the current time to compute a future time. The exact UTC designation of that future time may not be known in advance.
Okay, that's mean solar time then, not actual (apparent) solar time.
Many ham radio operators always know what time it is UTC as they participate in worldwide events. Some can even tell you what time sunrise and sunset are at interesting places across the world.
My wife has a friend who teaches classes to students in several countries and time zones. She does them by Arizona time which is among the most confusing time zones to folks from, say, India.
We tried the UTC experiment in our household once. Lasted about half a day.
Haha. Me and my friends did this throughout middle school. My experience was similar; the biggest downside is social.
These days, dealing with clients scattered across disparate timezones, no matter what, you either gotta deal with calendar differences or jet lag.
Good time to remind ourselves to always log in UTC. Yes, always, no exceptions.
Thinking about the future, if humans as a species become interplanetary, keeping up with lunar time, asteroid belt time, martian time,etc.. is going to be a mess. UTC is the only way to go.
timezones are artifacts of olden days where people didn't communicate across great distances and worked fixed daylight hours. Much like being able to speak the same language, being able to use the same time across vast distances is a huge boost to productivity and progress. This is kind of like using the metric system, vs using local/traditional measurements (like the US does).
> Thinking about the future, if humans as a species become interplanetary, keeping up with lunar time, asteroid belt time, martian time,etc.. is going to be a mess. UTC is the only way to go.
You can approximate UTC elsewhere in the universe, but it's going to be weird. You'll have the vary the length of your seconds as your velocity relative to Earth changes.
If we regularly have groups of people away from the earth, we'll probably want to follow a time standard that approximates a clock at the center of mass of the solar system.
I have also used only UTC for any time display in any of my devices, clocks, computers, mobile phones, but for much more time, for at least 20 years.
I find it easier to keep in mind the current time zone offset and add it mentally to the displayed value when that is necessary (i.e. for comparison with time values coming from external sources, e.g. event schedules), regardless if it is summer or winter or I am in a business trip in another time zone, than to change the displayed value to reflect the correct local time when needed, and then to account for that.
> After an eight-hour flight, if you went to bed at 21:00 yesterday, you’ll do the same today.
I would like to hear more about how that works out, you don't shift to sleep cycles at the place you are at, you just always go to bed at 21:00 UTC?
Why not use International Atomic Time (abbreviated TAI, from its French name temps atomique international)?
Because if we're abolishing timezones, we gotta keep a little fuckery. Leapseconds keep people on their toes. TAI would just be too simple.
While I don't use UTC for my local devices, I use UTC for any logs on remote machines, servers etc. It solves all kind of problems of trying to remember or have to care about where they are (I have machines in multiple time zones).
But yes I wish sometimes everyone had one standard time, trying to book a meeting with Chinese people AND west coast people while I am on the GMT line are a nightmare, as it isn't even the same day anymore!
I’m convinced we need to move to a world time. The Internet is part of life and we have people coordinating around the globe. Time is time everywhere.
Sunlight is different everywhere. But not everything timed is tied to sunlight. There is no reason that the time should be 12:00 at peak sunlight locally.
UTC is an issue near the international date line. I could see residents of Pacific islands wanting to not have the date change mid-day. Should think about adding hours 24, 25, 26, etc. to Wednesday that are equivalent to hours 0, 1, 2, etc. on Thursday.
(And as a quant who did a lot of time programming for financial markets, fuck Daylight Saving Time and the leap second.)
The way I see it is you are deciding between making the instant very clear or making their "time of day" clear.
But IMHO "time of day" is less important because 1. People in the same time zone still have different schedules so it is an approximation anyways. 2. If you know what instant is being discussed it is very easy for each person to relate it to their personal schedule.
So I agree that switching costs aside using UTC would be better overall.
Timezones, or something equivalent, are here to stay for the foreseeable future because we live on an approximately spherical world, its rotation is not tidal locked to its star, its rotational axis is not perpendicular to its orbital plane, we evolved to synchronize our biological rhythms including our sleep/wake cycle to local sunrise and sunset, we occupy a wide range of latitudes and longitudes, and we need to coordinate activities with people who are far away from us.
I wonder sometimes, if we were living in a world that never had timezones, and instead everyone standardised on UTC, what would the case be for introducing timezones?
I'm not sure this makes coherent sense.
The timezones are a formalization of existing practice, the way modern Metrication is a formalisation of practices which date back to early Weights And Measures laws.
In both cases people didn't wake up one day and from scratch invent the present sophisticated systems, they iterated, once upon a time the kilo was roughly "this much", by the 19th century it was a platinum iridium model object (the "international prototype kilogram"), today it's defined in terms of the measured constants of our universe.
Once upon a time midday was whenever the sun is directly overhead, people iterated, fast transport such as railways led to the use of standardized clocks and gradually there's a "standard" time agreed over whole regions or nations so that midday is whenever that standard says it is.
The timezones just codify and structure this existing practice. If you tell the people of Kyoto that midday ought to be eight minutes earlier than they've been having it so as to line up with a Japan-wide national time system, that's a minor annoyance. But if everybody in the world "standardized" on UTC that's eight hours different, I repeatedly tried to work out what happens, I kept getting muddled, I suspect residents experiencing this would fare little better. No.
We would invent them for the same reason they were invented for the first time.
I don't really care what time it is in England; I care about the local solar time where I live. I live in Tucson; the local solar time at my house is about 7.4 hours before UTC. I and the people who live near me would quickly start informally referring to times based on the position of the sun: "let's get lunch tomorrow an hour after solar midday".
(Aside: this isn't just hypothetical. It has happened in the real world. In the far west of China, people have settled on a different time zone for colloquial everyday use, which differs from the Beijing-imposed official standard time by two hours.)
So far so good, but someone on the far east end of Tucson is more than a minute later than me; if we want to be precise, we'll need one standard for the whole city, so maybe they'd build a big sundial at the University of Arizona and that would serve as the reference for the whole city.
But people drive around Arizona a fair amount; it'd be annoying to have to adjust my model of time by five minutes every time I go to Phoenix, and I wouldn't mind the few minutes of slop applied to my own life in Tucson, so I'd probably just start referring to everything in terms of offset from "Phoenix midday" and "Phoenix midnight" to make things easier. And if we're going that far, we might as well make it an even bigger area: big enough to include the whole Southwest, but small enough that the difference from local time doesn't bother anyone. Let's say we base it on Denver.
Bam, we just reinvented Mountain Standard Time.
Well, almost. Meanwhile, people on the East Coast would have (almost) reinvented Eastern Standard Time, presumably based on their most important city, which is New York. New York is about 1h55 ahead of Denver in solar time. Dealing with these almost-but-not-quite hour offsets would be annoying, so we'd probably just standardize on one system for the whole country, with nice, even, easy to reckon hour-multiple offsets for everyone.
Canada and Mexico, whose economies are highly dependent on trade with the US, would soon standardize on the US-imposed time zones. Even if doing so might hurt their patriotic sense of national pride, the practical value would be too great. But what about the rest of the world? Well, our historical closest friend and ally in a far-off longitude is the UK, so why not sync up with them and make all those easy to reckon hour-multiple offsets from their most important city, London, or more precisely, the point they've chosen for London's standard time: the Royal Observatory in Greenwich.
Now we really have reinvented Mountain Standard Time, exactly as it exists in the real world.
Why wouldn't we go further and just use Greenwich time for everything? Well, because we still do care about local solar time. The difference from my house's solar time to the newly invented MST is less than an hour, which I can live with, but dealing with a 7-hour difference would be annoying.
I have all my cameras set to UTC, but I live in London so it’s at most off by one hour.
The great advantage of UTC is you don’t have to deal with the abomination that is daylight saving time.
I've been doing this for the last 5 years too with all my devices. Makes it nice when looking at logs
I have let through some timezone bugs, tho those bugs also didn't impact prod since prod machines are UTC
Done with both EDT & PDT,
I did have a mixup with catching flight: I read 2300 as being UTC (since I'm not used to 24h clock being localtime) & thought my flight was 7PM instead of 11PM. Would be nice if flight times were UTC, always annoying figuring how long flight actually is
I think a better approach is to just have a 2nd local clock for the region of interest.
Seeing two analog clocks side by side is the fastest way I can decode any concerns around the time difference. Digits on 24h UTC clocks makes my brain switch to a wildly more complex mode of operation.
My third job was medical telemetry and that was sufficient for me to not only put everything in utc but also correct for client server clock skew.
Problem is though with distributed offices and remote workers. “The servers started crashing at 10:31 can you look at it?” Doesn’t mean anything without more context. If it’s 10:50 local does that mean it started 20 minutes ago or 7:20 ago? 3:20 ago because they’re on the east coast?
The oddity I'd expect from this is that your local date changes at some moment other than 0:00. For example, in Moscow the date will change at 21:00.
That’s still at midnight locally though. What’s maybe odder is that your UTC date changes in the middle of the local day. So “tomorrow” can be “this afternoon”.
That does seem odd on paper, but in practice we already deal with that anyway from midnight being kind of arbitrary and not necessarily while we're asleep (almost never, personally) so we do things like scare-quote 'tomorrow' because really what we mean is 'my next waking period'. It'd be weird at first for sure, but once accustomed to it I don't think that would be a drawback personally, just a different arbitrary.
Makes no sense. As long as you are primarily in your timezone, why take the trouble of converting date/time every time you look at the clock?
Even if UTC itself is a bridge too far, at least consider a 24hr clock, in order to obviate that AM/PM ambiguity.
Many years ago I committed to setting everything to 24hr clocks. Even when I still had a standalone digital alarm clock that plugged into the wall; in fact that was the impetus to change.
Because it was very easy to miss a little "PM" pip in the corner, when reading or setting the time; and setting an alarm depended on getting the pip correct, so eliminating the pip for me meant eliminating ambiguity in the digits.
It's been a fairly successful transition, although sometimes I look at "16:15" and think it's 6pm so the "mentally subtracting 12" needs practice. And there are still special snowflake UI widgets that ignore my i18n settings, and constrain how I enter or specify a time.
I would settle for people and software just not doing that '06:00pm' type abomination. 6pm fine, 1800 fine (06/6am fine) but not 06pm.
PM is like ROT12 AM.
> Why care if the sun rises at 8 or 21?
Isn't that sentence contradicting the entire thing? If you don't care, then use local time. Unless this is satire that I didn't get :P
I'm not quite sure how you're reading it, but what they mean is 'the reason to have different offsets is so that morning/sunrise happens circa 8am everywhere in the world (in local times), but why is that a goal - why care if it's circa 8am or circa 9pm or anything else, it can be at different times in different places instead of them having different offsets to make it the same'.
Note I'm not saying I agree, just explaining.
Anyone remember Swatch internet time?
Came here to post this. :)
> As a programmer, I’ve always been annoyed by the concept of administrative time zones.
That's because you committed one of the capital sins for a programmer: you tried working with time. The old mantra "use a library" still rules.
> I decided time zones should be abolished, and everyone should use one coordinated time. Why care if the sun rises at 8 or 21?
You seriously need to go out more often.
> You seriously need to go out more often.
Pretty much that. Most mammals I can think of live by what the sun, one way or another.
You should live by the sun, regardless of what the clock says. The clock is useful for measuring time, and UTC, TAI, etc can be useful for that, but if you want to wake up, etc, you can do by the sun light. For local time, you can use the solar time, which can be used with a sundial.
Your thinking is incorrect. Most mammals are nocturnal
Source: https://pmc.ncbi.nlm.nih.gov/articles/PMC4183310/#:~:text=Gl...
Nocturnal would be “the other way”. It’s still based on where the sun is: below the horizon.
How do you be nocturnal without living by what the sun's doing?
Nocturnal animals are still living according to where the sun is, just as much as we are.
Good time to bring up my idea where time is expressed as offsets from sunrise, noon or sunset for a given lat/long coordinate.
What about UT1 (or UT0, UT1R, UT2)
That's great to have an alarm to 11am which is 7am at your timezone and be woken up at 3am after cross-atlantic flight next day.
Some people just like to add complexity to their lives and keep convincing themselves that it's better.
Anecdotally, I worked on a military facility where all clocks were in "master timezone" of the country without daylight saving offset. 6 months a year we put "+1" sign made of electric tape to not forget about that it's summer and 0400 is actually 0400+TZ+1. I worked there for 5 years and never got used to it.
Says the guy living 3 hours off UTC.
It's a little different when going to bed one day and waking up another doesn't happen anymore. And small numbers aren't morning, big numbers aren't night.
I hate this form of nerd clickbait. tech bro discovers UTC, thinks he’s cracked the code of the universe, and writes a navel-gazing manifesto about how changing his watch changed his life. of course it ends in a SaaS plug.
I've done this with 4/5 hour offsets & 7/8 hour offsets. You quickly build up a mental mapping to skip arithmetic. Numbers are just symbols
https://qntm.org/abolish, as always
Let's try and get rid of DST first.
The article focuses a lot on how this reduces friction when working across time zones but glazes over how it makes interacting with everything local require a conversion.
5 days a week I am working with people in Seattle, NYC, Munich, and often London or India. I have to coordinate meetings across time zones a lot. I travel a lot.
And yet at home or on the road I have to process things like "this store closes at 18:00" or "this train is at 16:45" infinitely more. Putting my devices in UTC requires me to think for all of those interactions which is way worse.
I live in Britain and I'm annoyed by the summer time. Worst is when you work with people in North America and the time difference changes 4 times a year.
"Bart, remember .beat? It's back! In UTC form."
This to me has some parallels with the original pitch for Soylent where it was like “why bother with human emotions that surround cooking and eating food when you can exclusively eat this grey tasteless slop for every meal of the day?”
Why deal with this stupid human construct of your day starting when the sun comes up when the sun isn’t relevant to your local data center?
Heck why not just count up milliseconds since 1970?
> After an eight-hour flight, if you went to bed at 21:00 yesterday, you’ll do the same today. If you had a call at 13:00 yesterday, it’s still at 13:00 today.
Wow. This is amazing. Who knew this only worked with UTC!! /s
Missives like this just make me embarrassed for us “technical folk”.