I first read this article several years ago and hated it. Giving it another shot, I still do. There are probably real issues that would come by abolishing time zone but they aren't raised here.
This article was written in 2015, when it was already extremely easy to search "What time does the work day start in Australia?". It's only gotten easier and easier as search engines implement smart widgets, of course, but even then it was not at all the medieval process described. (Finding a webcam in the city? As clever as it is stupid.)
> "It would be neat if there was a lookup table for that kind of thing."
There is now and always would be without timezones. Abolishing timezones doesn't mean people stop caring about time.
Agreed, I think it's worth a point-by-point takedown of the article's concerns:
> causes the question "What time is it there?" to be useless/unanswerable
necessitates significant changes to the way in which normal people talk about time
This is a significant benefit actually. The answer to the question would be: It's exactly the same time everywhere.
> convolutes timetables, where present
If convolute means simplify then agreed. Flights would no longer sometimes arrive yesterday or go back in time. Sure the position of the sun might be different at your destination but you can be assured that you will not land in the past.
> means "days" are no longer the same as "days"
Fair criticism but already days are not days. If a team on the other side of the globe tells you they will get it done today, are they referring to your time zone or theirs? This is easily solved by simply saying "I will get it done by 0500 (utc)" which is more precise and probably better anyway.
> complicates both secular and religious law
It's already complicated. When does fasting end if you live in the artic circle for example? It's easy enough to map the solar day onto the utc time. Sunrise and sunset fluctuate anyway based on latitude, longitude, local laws, and even terrain.
> is a staggering inconvenience for a minimum of five billion people
Why?
> makes it near-impossible to reason about time in other parts of the world
You already need to consider the offset to your local time, knowing a single offset to UTC rather than having to subtract two offsets is far from near-impossible, it's actually far simpler.
> does not mean everybody gets up at the same time, goes to work at the same time, or goes to bed at the same time
What flights go back in time? I guess if you take off near the edge of one timezone and land near the edge of another. But so what? Why is that an issue?
Most times I'm dealing with things local, I didn't really care what time it is elsewhere. And this is said by someone who just had several calls with people from around the world. Id rather deal with trying to figure out what time somewhere else is every once in a while rather than trying to understand what time midday is.
Generally when they cross the international date line - for example when traveling from Sydney to San Francisco, I can take off at midday and land at ~7am on the same day local time.
Yea I think this author completely ignores what you can do with technology. First of all, most people, today, will already Google search 'what time is it in Australia?' so there is already a lookup step.
No imagine replacing this step with 'is now a good time to call someone in Australia?' or 'what local times of mine are good to call someone in Australia?'. You can have a tool/app/algo which accounts for the differences in daylight, cultural differences in working hours, holidays etc and just tells you what a good time is.
I fully agree with the point you're making, but to be pedantic, clocks and timezones are themselves assistive technologies. The precursor to them was taking a look at your shadow and making an educated guess.
I’m fairly sold on abolishing time zones, but arguing that they make a programmer’s job harder is not a compelling argument when we’re a small percentage of the population. Yeah, it’s annoying, but that’s just part of our job. What’s really important is the impact on the general population.
Programmers are not the only people who deal with timezone problems daily, and as the world becomes more connected, more and more people will have to deal with them
If Timezones are difficult for programmers to model into our systems, then they are likely difficult for everyone to model in their brains
Simplifying the model benefits everyone, not just programmers
Does it really simplify the model? It rephrases my google query if I want to call a colleague in the Philippines. That's it. It does not make it better, easier, harder. It rephrases the question, it does not abolish the question.
For the most part, yes? Sure, the very first time I talk to someone in a new time zone I have to look it up, but IME with working with globally distributed teams you get used real fast to thinking "China is at -9 (+ 1 day)" or "Amsterdam is at +8".
That doesn't change without timezones, you only have to remember a slightly different fact (at which time does their workday start). No real benefit there to keeping timezones.
The biggest advantage of getting rid of timezones is when an absolute point in time is mentioned, e.g. the start of an event. It's so annoying when the start date for some global event is announced and they only include a local time in some obscure timezone.
If you're going to live-stream an event for the whole planet to see, use UTC. It's especially baffling that organisations such as SpaceX or NASA use local time instead of UTC. You'd think that anyone dealing with things in orbit would use UTC.
Cool. You already have the knowledge you need to figure out what party of the day it is in another timezone. Now when you say let's meet at 10, you don't have to figure out which 10 you are meeting at.
If time zones where abolished you do t have to worry about what time zone a written time is in (is the 7 eastern or central or GMT or etc) its always 7 UTC.
Then you can take the SAME knowledge that East Coast of the US is 6 hours behind UTC, to figure out that 13:00 is the morning for them.
A lookup table for what? If everyone is living on the same time, what exactly are you looking up? The only answer is "local solar time", in which case you haven't "abolished time zones", you've just made them eight billion times worse by making them informal and person-dependent instead of statutory.
>A lookup table for what? If everyone is living on the same time, what exactly are you looking up?
In the context of the webpage where that is quoted, it means looking up the typical activity for the time in that location. By avoiding the look up of time zones, you haven't really reduced complexity and only shifted it somewhere else because now you're looking up relevant "activity" windows for that location.
You always have 2 components of a key-value dictionary in either system. (1) the "fixed" a familiar knowledge you have as a "key" and then (2) the lookup "value"
- Timezones system: (1) fixed knowledge key is "I know people are awake doing school & business between ~8am to ~5pm and sleep ~9pm to ~6am" for entire globe --> (2) now lookup what timezone they're in : e.g. "California TZ is UTC-07:00"
- no timezones : (1) I know the entire globe is on identical time --> (2) now lookup what numerical values correspond to "awake vs sleep time" in that part of the globe : e.g. "California school/business hours are ~3pm-12am UTC"
This is a very nice summary of what I was feeling but couldn't find words for. Those advocating for abolishing timezones are merely shifting one problem to another, without any obvious advantages which can overcome the obvious disadvantages.
Things like "when do people start work in Brisbane" is not universal across all people in Brisbane, knowing "on average when do people start work in Brisbane" is not terribly useful
Today, if you need to contact a business in Brisbane, you start by looking up their hours, then you convert timezones, then you plan your contact
Without timezones, you no longer need the second step.
Similarly if you are planning a meeting with someone in Brisban you can just say "Does tomorrow between 4 and 8 work for you", with no timezones involved
But what about local Bisbanians? They have lived their whole life with a certain timetable. And now suddenly you want to impose a new timetable on them? For what benefit?
So far, I used to think that people were joking when they advocated abolishing timezones. Now that it seems some are actually serious, then I have a serious question - how do you plan to convince the local population to adopt a completely new time?
For example, I am in SFBA and if there is a vote to shift our time by 8hrs to align with UTC (global timezone), I would vote no. I don't see any benefit in shifting my day by 8hrs and instead of sleeping from 10 to 6, start sleeping from 6 to 2. Oh wait, or would it be 2 to 10? Ah nevermind, too complicated. Let's just continue my current lifestyle because the cost of switch is too high for no obvious benefit to me.
Somehow I think if your phone and computer updated automatically to the new timezone, and your boss told you what time to get to the office the next day, you'd somehow figure it out without much trouble. People do this every single day when they travel, and many places already do this twice a year with daylight saving time shifts
It would feel weird for a while for people no doubt but times already are arbitrary anyways. Why does it matter if you sleep from 1-9 or 13-21?
> you'd somehow figure it out without much trouble
No it would still be a tremendous hassle. I have a much larger life than my phone, computer and boss. Like, kids - explaining to them the new time change and teaching a whole new schedule ("start bedtime routine at 4:30 instead of 8:30pm") alone would make me vote against this change.
> Why does it matter if you sleep from 1-9 or 13-21?
Because you haven't told me what's the benefit if I do that.
They're already informal and person-dependent. When does someone wake up when they're on night shift?
The problem we have today is that we have mass confusion as to when common events like meetings are. In a distributed society like ours, it doesn't matter if I wake up at 04:00 or 17:00 but it does matter when the basketball game is or the meeting is or when the company in Lebanon starts.
The constraints of our society have changed. People in India work the hours in London. People in Florida work the hours of California, and vice versa.
And as we see, we already have countries that span four "natural" time zones and Western China has some ability to adjust.
The thing that would probably be in the lookup table would be official government business hours or something of that nature. It could also be schools, shops, or restaurants. That gives you a good idea of when "daytime" has started regardless of if it is winter or summer.
Why, we could even publish our own individual "official hours". Those of us who stay up late and go to work later (referencing solar visibility) could publish later hours, and those of us who rise before the sun and retire shortly after dark can publish those hours.
Eight billion time zones, all available at a glance, with their contact info — Yay!
(I'm not sure myself if this is real or sarcasm, but if it was all UTC, it sure would be one good convenience for caller and callee)
to use the article's example though — if you want to call your uncle Steve, you're thinking: is it a good time? i.e. is he likely interruptable or would he be in bed/getting ready for work/at work?
Sunrise/sunset doesn't really give you much of an idea for those, (as you move aware from the equator, at least)
You call, if they're available they'll answer. If they aren't you leave a voicemail and follow up with an email.
If they don't want to be woken up in the middle of the night you turn on do not disturb on your phone (and most phones let you exempt specific contacts from DnD, or a 2nd call from the same number)
Oh my goodness, the irony of your username while arguing against precisely defining the sun's position in the sky!
But you're still correct: When most people are using time in conversation, they need it to be meaningful with respect to solar time. If your replacement method can't do that, no one will adopt it.
Probably just about anything you want, as is already commonly available.
Mostly, I expect nations would have official business hours for public employees which would be easily searchable if you needed to call someone on another side of the world, which is not any more difficult than looking up what time zone they live in is now.
It's good summary of why it's a totally insane idea, and yet whenever it comes up on HN there are always a lot of commenters who are still in favour of it.
I would say the post would fare better as "Use UTC (or GPS, TAI) in certain contexts". I work remotely as does my team. Our timezones are up to 9 hours apart (maybe more with DST differences). When working on production issues UTC is best. When talking less technically it's good to add -0400 (or EDT if everyone's familiar). Even then UTC is still pretty good as most of the team's in EU/UK and can deal with that well.
Many of the issues it brings up are already an issue if you work across timezones. For example "today" is already ill-defined if you're in the US and have a team in India, who's day does it refer to?
It'd be much easier to just have a single "timestamp" that everyone uses then think about offsets from that.
I don't want to abolish time zones, I just want all the servers to run on UTC and all the apps to use standardized date/time libraries. Is that too much to ask?
As a web dev, I've spent more time and effort debugging datetime issues (across the frontend, backend, databases, and customer implementations) than all other classes of bugs put together. It feels like every year there are many days/weeks spent looking for these these, fixing them individually, and fixing them again at the meta level to account for the different ways people tried to fix them individually :(
The most enduring fix is almost always like you said, store timestamps in UTC (plus a zone name string separately, because an offset isn't always enough), plus use standard libs instead of trying to do your own datetime or time zone math, then format timestamps into human readable localized dates as late as possible for the user. In JS that means Luxon or date-fns instead of the woefully inadequate built-in Date methods.
For whoever uses PostgreSQL and needs to see this:
1. Please, please use native datetime objects instead of integers. A bigint (needed to represent datetimes past 2038) is 8 bytes, same as `timestamp`.
2. Please, please store explicit timezone values. Even if they're all UTC and it "feels redundant". `timestamptz` and `timestamp` are both 8 bytes in Postgres.
If you can't articulate the 10x advantage an integer gives you for your particular app (they are vanishingly few in 2024), please, please use `timestamptz`.
I did this at work - all cloud servers are at UTC at all time!
(The fact that we have offices in multiple timezones helped to motivate it).
This worked out pretty great IMHO, although I sometimes still have to convert the local timestamps for interaction of systems like Slack.
> I don't want to abolish time zones, I just want all the servers to run on UTC and all the apps to use standardized date/time libraries. Is that too much to ask?
Err, maybe you come from Windows?
In all variants of 'nix I'm aware of (and we are going back to the 1980's here), the kernel time is always UTC. You then set your TZ environment variable to reflect whatever timezone you are in.
Why? Well because back in the day we had time sharing as computers were far, far too expensive to be used by just one person. So from day 1 'nix assumed people would be logging in remotely, and when they did "date" had to display the correct time. In fact all time stamps were stored in UTC - including in the inode (eg, file modification times) and of course archive programs like tar used UTC exclusively.
Time moved on, we got PC's, and so the model moved to being one Computer was devoted exclusively for the use of one Person. DOS, and later Windows hark from that era and not surprisingly they too the opportunity to ditch all that UTC conversion complexity and store everything in local time.
But in a bizarre turn of events as computers got even cheaper they became so powerful they could services 100's or 1000's of people at one time, and with the rise of the internet it became cheap to connect them to those people. What's more it became profitable, as mum and dad just didn't want to handle the complexity of managing their own computer systems. Instead they pay someone else to do it. Fair enough I guess, but boggles my mind when youngsters here who evidently class themselves themselves as "computer professionals" say it's far too difficult to maintain computer hardware and systems, it should be left to the experts like AWS and Azure (at 10 fold mark up, thank you very much).
And so here we are, what was old is new again, and you are asking "please can we just store everything in UTC" because everyone shares computers.
Well, we did son. Then you young'ins came along and fucked it up.
> I want to call my Uncle Steve in Melbourne. What time is it there?
>
> It is 04:25 ("four twenty-five") there, same as it is here.
>
> Does that mean I can call him?
>
> I don't know.
I'm normally just doing a mental mapping of when's good to call someone based off my time anyway, and their usual habits — "My brother is normally free to catch up when I get off work at 5pm". Rather than — "My brother is in France and there it's 6pm, therefore it's a good time to call him."
If I don't know, I'll send someone an IM — hey Steve, fancy a call to catch up? I'm free for the next hour or so if your around now. Otherwise I'm free all day Saturday.
Time zones are definitely annoying to deal with in software, but conceptually they’ve always seemed like the least bad option. The thing that’s annoying is that they’re always changing and sometime on fairly short notice.
The things that have worked for me are:
- Storing dates as dates, not datetimes. Sure, you can make sure you always treat them as local/timezone less, but someone at some point will apply a timezone to them and it will break.
- Integrate pulling the latest zoneinfo as part of your CI.
- Store everything as UTC and use the client’s TZ for rendering.
How to deal with customers changing their timezone is always tricky too. “Do they want this to run at 3PM local, or 3PM of their previous TZ?”…
Okay, let's keep timezones. You still don't know if it's appropriate to call your friend in Australia at 8AM their time, even if it totally is in Switzerland. Nor do you know whether calling at 8PM will interrupt someone's dinner or not.
Even within the same timezone, countries/cultures differ. And even within the same country/culture, people differ.
This particular one I live with constantly being in tech and living on a ranch in the US west.
I'd never call a tech friend at 8am, I might well wake them up. And I'd never call a rancher after 8 - they will be working without cell. 6-7am is ideal they will still be working, but hopefully inside cell range with a cup of coffee.
It is still a lot easier to remember information like “Portuguese people tend to eat dinner late” than “the average Portuguese dinner time is from <some UTC offset> to <some other UTC offset>”.
This is really an incredibly narrow use-case in the modern world. It's very easy to ignore a phone call nowadays if you're busy. Avoiding global times just to gain an incredibly inaccurate estimate of when someone might be busy is not a very compelling argument.
Let's imagine we have no time zones and the article is trying to make fun of introducing them.
Before introducing time zones
I want to call my Uncle Steve in Melbourne. When does the evening start there? Google tells me it's 8:00. Better not call right now.
After introducing time zones
I want to call my Uncle Steve in Melbourne. When does the evening start there?
It's 20:00, same as it is here, of course! Same as it is in New York, Bangalore and Hawaii, at the South Pole and on the Moon.
Well, hold on a second. First of all, we need to straighten out some terminology. What does 20:00 mean exactly? It's strongly deprecated now, because now it refers to the position of the Sun, not of the clock.
And then it goes on like this for 5 pages...
Imagine we had universal time across the globe and someone tried to introduce time zones. It would seem like a batshit crazy idea to everyone.
This article takes far too long to get to the main objection against using a global time: for a large part of the world population it will break up the local day and spread daily activities across two days. That's a far bigger inconvenience than some extra workload for programmers and people who need to schedule cross timezone activities.
I'm not fully convinced it would be an actual problem.
So what if my Friday workday spans two dates? Wouldn't "Friday" just be my local day, which spans March 14-15? I feel people like the author would be intentionally making things difficult by referring to local days and absolute dates by the same names without making efforts to differentiate. In reality, language adapts rapidly for convenience in most cases.
From a dev's point of view, timezones in real life are okay and much more annoying in data/software because sometimes, other folks don't care about capturing timezone offsets properly or converting to UTC.
We all just long for clean UTC timestamps that can be created, parsed or passed around without concern until they are displayed and formatted according to a local timezone where ever.
Abolishing day time savings would simplify this even more.
As a best practice though, you shouldn't store offsets but rather time zone identifiers. Reason being: time zones change offsets. DST being a good example, but they also change for geopolitical reasons and more often than you'd think.
I think iOS used to have it as well. Gnome2/Mate had a fantastic day/night view of the Earth in its calendar widget as well. Didn't seem to make it to the new dumbed-down desktops sadly. I've used xplanet for this too.
Even in the old days, you should have looked it up before placing an international call.
Anyway, you're going to need technology to solve this one way or the other, especially when meeting folks halfway around the world. So everyone using UTC is not an impediment. Just a different way of working, which is the hard part. But not everyone has to change at once. Could be one organization at a time.
Not even saying I'd prefer it, but it is reasonable to try.
This article presents one approach to doing away with customary time zones. However, there are other approaches that aren’t so jarring in these ways, though maybe in other ways, just as our current arbitrary convention is also jarring. All this to say, the article wasn’t persuasive.
Another approach might be infinite time zones, which on a local level is deferential to local customs. For important times (like transactions), UTC still exists. But, for meeting at the pub, church or school a two second difference from your house isn’t meaningful. Probably each regional hub would recognize its own solar noon anyway. So still regional coordination, but smaller regions than 1-timezone China.
Having lots of ad-hoc tine zones is worse than having a few standard ones. Every event has to specify the exact offset, and every attendee has to specify theirs. One big advantage of time zones is that large areas keep the same time and most commerce is inside time zones.
If you mean local solar time, you need to realize that changes over short distances. At my latitude, one minute is 9 mi. I have coworkers that commute that far to office so they would have to keep track of home time and office time. Or they would be late to Zoom meetings.
Well, lots of time zones being an infinite number of time zones in that thought experiment.
You see, not every event has to specify the exact offset because in practice:
1. If you’ve got coworkers who are a minute late attending a meeting, no one cares. Or, they show up four minutes early instead of five.
2. This level of formality (keeping track of home and office time) is a ruse. A minute here or there is constantly lost or gained with traffic, tasks or luck.
When that precision is needed, I’m sure your calendar + gps on your phone can give you the exact nanosecond you need to join the Zoom.
For humans, time is relative to the individual. When absolute coordination is necessary, computers step in and nudge you along. Turns out they’re good at that.
The time difference grows over fairly small distances. If you go to nearby city, it can be 15 minutes difference. That is the difference of missing an event or shop being open.
There are lots of things that are accurate to the minute. If you are a minute late, you miss your bus. Also, what time does the bus use? Does it change time as it moves or keep consistent time?
The coordination basically requires computers. All watches need to have GPS. All computers need to have GPS. Every event requires someone to enter the official time/location. It would be impossible to accurately schedule anything over the phone.
Local solar time wouldn't be for humans but for computers. Humans invented time zones because of the problem with local solar time for railroads. We much prefer consistent time zones for day-to-day.
Isn't the infinite time zones thing basically how things used to work, until train schedules brought cities more in sync with each other in 1883? At least in the US, that is.
The line that matters (from their continuous time article):
>At the equator, the position directly underneath the mean Sun travels west at about 463 metres per second. That means a standard [server] rack unit is about one millisecond wide.
One local time zone problem I hadn't anticipated, in an early startup...
I made our launch networked factory stations use UTC, to aid debugging with the various servers involved. (Such simplifications help, especially in debugging and incident response, especially when you don't yet have centralized observability.)
But the first time I had to investigate a problem remotely, on a station at a factory in Asia, the timestamps from various systems weren't lining up. I quickly realized that the station clocks had somehow gotten set to local time there.
Turns out that, when some of our team flew out to install the stations in the high-end factory in Asia, factory personnel noticed that there was a UTC time on screen for a few seconds during station startup, before it finished booting into the fullscreen appliance UI.
Factory personnel were so alarmed by a factory machine with the "wrong" time, that my people on the ground made the decision to change it to local time. (I suspect it was alarming because some other factory machines had operation procedures for personnel to ensure that the time is correct.) And in all the excitement of a successful launch, they forgot to tell me.
Maybe an additional reason against a single time zone: aoption resistance from people who don't understand, or who just like the local time.
For example, I can imagine many people stubbornly using "shadow" time zones for various purposes, and only using the official time zone when required (and this being error-prone).
There was a small communication failure incident: not telling me about a judgment call, in all the excitement, and when we didn't have comms as it was happening. (I have a few other stories about comms there, for another time) We addressed that oops constructively, as soon as it was realized. But that's not the problem I meant to highlight.
The problem I meant to highlight was that there can be surprising local resistance to something like UTC time, from people who aren't IT nerds. In this case, resistance to something we didn't even think they'd see during boot. And that prompts thinking about other ways there might be resistance, and what might happen due to resistance.
The factory manager and staff have their own way of doing things, and part of working well with them is figuring out what that is. Especially when you'll be thousands of miles away if problems come up. It turns out some things were intuitive, and some things weren't.
The people on the ground made a judgment call that this wasn't the thing to communicate harder or spend political capital on, and I support them making that call.
This is a pretty dumb objection. There are many things that would need to undergo a difficult transition if one were to abolish timezones, but the google answer box is not one of them. If time zones were abolished then "time in melbourne" would say "2 hours to sunrise" and the before and after would be functionally equivalent.
Invariably, there is a thread from someone new to the mess that is 'time' that discovers things like leap-seconds or Japanese Imperial Years and is just blown away at the insanity of it all. Then there are discussions on how to implement the logic, with much cursing at Excel. And then someone mentions relativity and everyone just sighs and acknowledges that old Paul Krugman paper.
I used to work in an atomic clock company, so all the issues with 'time' are a bit old hat for me. But it's always a blast (honestly!) to see new people's heads explode in these comments as they slowly realize that 'time' isn't really a thing thing. Like watching chicks hatch.
I don't want to abolish time zones. But I would like them to be more standardized.
I don't know who else has looked at a time zone map, but it is a clusterfuck. And that's putting it mildly.
In so many places, you can tell the time zones are set politically, not geographically. Which goes against the entire philosophy of time zones. I should not be able to drive due north/south and change time zones.
I'm not surprised that certain regions in China use a local time as opposed to their "official" time zone.
I also think that's a lot of the reason behind the resistance to standard time year round. Some people live in areas that are geographically in the wrong time zone, so their solar time is already fucked.
this is the best reason to eliminate them - their crazy borders (esp in Pacific Ocean) betray that they're totally artificial and not actually necessary.
If we abolish time zones, I’d like the option to choose if my day goes by “solar time” or just stick with whatever is most convenient for say a group of people working elsewhere on the planet/solar system.
I think the article is way too negative about something that’s easily solvable with no more effort than what is required today to keep track of someone’s time zone and DST.
I don't think we should abolish time zones, but he isn't making good points.
His points are based on conventions that exist because we use local time zones and he uses a lot of English centric bias in his argument.
His first point of am/pm is already a bad start considering a 24h clock is simply advantageous and used throughout most of the world.
Finding out if he can call his uncle would be as easy as looking up daylight times instead of time offsets/local times. And even then the cultural conventions of your country might not map to his and it was still inappropriate to call.
The problem with business hours and overlapping days is entirely made up, because he wants to stick to previous conventions that worked well with local time. If a night club opens Saturday from 19:00 to 05:00 it's perfectly clear that means it's open till Sunday 05:00. It would work similarly for business hours. The regular business hours also differ vastly in different cultures and jobs! The day name is of course UTC based and wraps at 00:00UTC.
I play an international online game that wraps days at 00:00UTC and we communicate in UTC. If I say Wednesday 14:00 UTC it's perfectly clear what that means and you get used to that very quickly. If we would change the system the next generation would grow up with that system and it would be natural. And I find it much easier to remember that my Korean friends are available from 23:00 UTC till 16:00 UTC than to remember what time it is there right now compared to here, because that requires mental math or a lookup.
No no. The idea behind abolishing time zones is that everyone then lives on the same schedule. It's just that for some people the work day will be in the middle of the night, etc.
Some longitudes would probably wind up more sparsely populated than others, but the world's large population of night owls would finally be able to truly coexist with...you lot
I have long suggested the more extreme solution. Getting to the bottom of our problems with calendars and time in general. We should simply remove Earth and Moon from equation. This would allow moving to metric year, months, days and even hours and minutes. Much cleaner and saner system. No more issues trying to fit these together.
> The [French Republican] alendar consisted of twelve 30-day months, each divided into three 10-day cycles similar to weeks, plus five or six intercalary days at the end to fill out the balance of a solar year. It was designed in part to remove all religious and royalist influences from the calendar, and it was part of a larger attempt at decimalisation in France (which also included decimal time of day, decimalisation of currency, and metrication)
> Each day in the Republican Calendar was divided into ten hours, each hour into 100 decimal minutes, and each decimal minute into 100 decimal seconds.
> The month is divided into three décades or "weeks" of ten days each, named simply:
See, that is still stuck to 12 months a year or 30 day a month... If we did not have Earth and Moon we could get rid both of those notions. And build something now non-existent ground up from seconds.
I also forgot to motion timezones, leap seconds and leap years...
Unless you are suggesting removing the solar day and solar year, you fundamentally have a little over 365 Earth axis rotations per Earth orbits.
Attempting to build decimal parts fundamentally results in ~36.5 deci-days. Assuming we extract the non-integer part with intercalary days, we are still left with 36 deci-days which has a prime factorization of 2*2*3*3, so you can choose 2:18, 3:12, 4:9, 6:6. Might as well choose 3:12 since it is closest to the current system. I guess 9:4 might also be reasonable to denote entire seasons.
In your first comment you said metric year, month, day. So it was unclear since a year and day are inherently solar concepts. It would have been clear if you just went straight to kiloseconds or similar.
You also did not include the Sun in your list which is a fairly big oversight if you meant to do away with the current solar day and year given the Sun is the dominant temporal determinant of our existing calendar system. You excluded the thing that gives the calendar its name. Getting rid of the (Sun and Moon) or (Sun, Earth, and Moon) would have been clearer than the ambiguous (Earth and Moon).
Exactly: earth+moon but no sun mentioned + ymd => year and day are solar things, month is a division of year and a multiple of day that already has little to do with cosmic things as a unit except that when grouped it lines up with seasons which is also a sun thing - equinoxes and solstices.
If we remove everything cosmic then we might as well do away entirely with ymd terms. kilosec, megasec, or whatever.
But! Removing the sun makes it immediately extremely impractical for scheduling: to schedule anything you'd have to constantly refer to an almanac - however rough - of the sun's position as, being completely removed from the sun and the biological constraints of circadian rhythm, time tracking will inevitably drift and offset to the point that it's impossible to reliably ensure actual people will be available for an appointment in 10ksec or 20Msec - whatever these secs are - in any intuitive or sensible manner that maps to the way biological beings fundamentally function, both at the solar day level (very fundamentally so) and the solar year level (less perceptible than day-level but still fundamental).
I mean, if I ask you what were you doing at 1610403576 unixsec or are you available at 1810403572 unixsec it is impossible to answer if you're even going to be sleeping well into the night without looking a sec-sun table (an almanac) up. The fact that unixsec as a duration is our current sec is immaterial - it could be anything so it might just as well be that one - as we just decided we're entirely removing the sun from the equation and defining secs in terms of fractional days would run against that. "well, I'll be sleeping" is the most common "not available" situation that we all share for ~1/3 of a day, everyday. Not exactly a corner case.
Consider that shops would not even be able to have "opening hours / days" signs on their door! Or dropping kids at school, setting an alarm clock, planning a trip to arrive at dinner... There's so much implicit scheduling around us that we're fixated on the comparatively small times where we have to open a calendar app (and even smaller when we have to cross timezones but that's not the topic of this specific thread). "I'm using a calendar already so everything might just as well be in the calendar" just doesn't stand up to the real world.
Since it's so impractical it follows that the only reasonable base unit of measure is not an arbitrary second† but the sun-bound day. The same argument can be run down for the four-beat-seasoned solar year, which allows us to intuitively grasp and anticipate so many things and organise as a civilisation - even when technology fails on us - that we take them for granted. And then, from that, we end up with a calendar shaped one way or another like the French Republican one.
† Even that could be challenged as our hearts beat at a rough ~1 beat/s at rest so there's a deeply grokked biological sense of time for us tied to that duration: 20s kind of resonates and that duration can be felt. Make the second half or twice and it's lost.
As another interesting idea: How about abolishing time zones so a day is evenly distributed around the earth. I.E. your clock is slightly faster/slower than your east/west neighbors clock is. And since your phone is a computer with gps it can smoothly add and remove time as you travel east/west.
There is just under 24 hours in 1 Earth rotation (which can actually vary a bit). Beyond that there need be no further alignment between a clock time and relative solar position. After all the relative solar position can vary significantly through the year and more so the further away a person moves from the equator. So, let’s dispense with any further discussion that convolutes clock time to relative solar position because it’s stupid and unreliable.
That being said all that matters when making a call is the availability of each party to the call. If one of them is sleeping at that time then they are clearly not available.
So, if you want to abolish time zones all you need to do is:
1. Use a 24 hour clock instead of a 12 hour clock. Stupid easy.
2. When making phone calls know the availability of people you are calling. You should be doing this anyways, but maybe you’re an asshole and consideration of others becomes an insurmountable impossibility.
3. Take some personal responsibility to know when there is and isn’t sunlight hours for your current geographical location.
That it. All further challenges come from stupidity and those challenges will remain regardless.
Arizona doesn't have any issues. They're standard time year round.
We _should_ abolish DST. The issue is that there are people who want to abolish Standard Time because, I don't know, they have weird notions about how awesome it is to have the sun up at 8pm. Or don't understand that there are just fewer hours of sunlight in the winter in general. Yeah, it's going to get dark earlier, it's a thing that happens every year. It's better to have early morning sun than late evening sun.
And the last time we tried abolishing standard time, everyone hated it and we went back to switching between daylight and standard. But places that abolish daylight savings time never go back.
It's a case where people are particularly stubborn about wanting to validate their feelings rather than do the thing that would actually work. Because people bitch and bitch about standard time in the winter and think they're bitching about the time system. When really, they're just bitching about it being winter, but they don't realize that.
> It's better to have early morning sun than late evening sun.
Is there actual data backing that up or just your opinion?
I personally really enjoy more hours of sun in the afternoon and early evening. As an office worker most of my mornings are just waking up and getting ready for work, not normally lots of time for recreation. Having more hours of light later in the day aligns with my free time hours better.
There is data backing up that early morning sun is better. It being light out when kids go to school and when we drive to work is more important. There are also things about our circadian rhythms and what not.
The "more hours of sun" is only an issue in the winter. In the summer/spring/fall, the sun goes down at reasonable enough times for you to still do all of your recreation. But in the winter, the sun is going to go down earlier anyway. And what sort of after-work recreation are you doing that requires the sun to be out?
More than safe, it would be the best option to abolish it completely.
In brief, our bodies evolved in the the movement of the sun, not numbers on a clock, so called solar time. Standard time aligns the numbers on the clock the best with solar time for most all of the world. There are some exceptions along the equator and at the poles at different times of year, but those are exceptions that have been, and can continue to be, handled well by people in those areas.
Go far enough from equator and that will happen anyway, or for some of us sunset at parts of the summer and sunrise parts of the winter are both NaN. But the change between standard and DST makes a big difference for some weeks during spring and fall
If you want to align things to solar time you probably also want seasonal opening hours - less in the winter, more in the summer, or such. Changing the clocks by an hour doesn't get you there though, only partly mitigates it.
Under the existing DST system (1 hour difference from Standard Time) they currently go to school (wait, children in school in the summer?) 3 hours after sun up but that's not seen as a problem?
There was a limited time between standardised time across a country or region, and the creation of DST.
Before the 1800s the day began when the sun came up, this varied every day. Clipping this to specific hour is far more sensible for a global community.
> Before the 1800s the day began when the sun came up, this varied every day.
See (variable-length/unequal) temporal hours:
> Adapting the European clock designs to the needs of Japanese traditional timekeeping presented a challenge to Japanese clockmakers. Japanese traditional timekeeping practices required the use of unequal time units: six daytime units from local sunrise to local sunset, and six night-time units from sunset to sunrise.
> As such, Japanese timekeepers varied with the seasons; the daylight hours were longer in summer and shorter in winter, with the opposite at night. European mechanical clocks were, by contrast, set up to tell equal hours that did not vary with the seasons.
Standard time keeps noon relatively close to the middle of the day, and midnight pretty close to the middle of the night (which, as the article suggests, is the entire point of having timezones).
Summer "daylight time" tweaks that by an hour (or two?) in order to make customary "waking-up time" closer to the summer sunrise.
Permanent daylight time just shifts everything over one timezone to the east, which to me seems kind of silly (along the lines of the "these go to 11" bit in Spinal Tap) but does have the benefit of not having to rename things like "the 11 o'clock news".
It is, my region (outside the US) got rid of it and I couldn’t be happier. Other than a few systems/apps with the wrong time causing some inconveniences, I didn’t hear of major issues.
In the Netherlands I would really hate to be on winter time in the summer (the period of the year that evening light after dinner is long enough to do outside activities becomes much shorter) and summer time in winter would be absurd. I hope they never change it.
Kids get out early... like 2PM. Unless you're a bank teller you can start an hour early. It will make you look like a harder worker +1.
Your kids will grow up quickly and you could change jobs over a year or two if it is particularly inflexible. Whatever your situation, it is a short period of your life that can and will change.
A time system doesn't have to solve everyone's problems, in fact it couldn't if it wanted to. Basically the point is to solve your own problems as you see fit, not push one solution onto everyone else.
The problem with abolishing DST is you have to decide if you want to have year-round summer time or year-round winter time. Many people say they want year-round summer time, but the last time the US attempted it, support for it plummeted after just one winter on summer time and DST was restored. (FWIW, scientists are almost universally in agreement that year-round winter time is the best compromise, but it's by far the least popular option.)
I'm proponent of year round winter time. And allowing changing of schedules when possible. If people want to work earlier let them or have them negotiate for that. On most areas I don't see reason why it could not be done.
No, abolishing DST is very safe. My sense is that there's a certain type of programmer who gets a little too hopped up on "abolish DST" arguments, and also is sick of time-zone bugs in their code, so jumps straight to "abolish time zones! everyone can all live on UTC!". Such people need to be gently informed that is a terrible, extremely radical, and totally unworkable proposal, and this article is trying to do that.
What about my perfectly reasonable and rational idea to have infinite time zones, all based on solar noon for whatever longitude you (or the system) are currently located at? I'll even compromise, we can limit the resolution to a single geographic second instead of infinite.
If only the idiots in charge would accept my brilliance.
That's traditionally how things worked prior to railroads in the second half of the 19th century. Every city and town would use the official time on a public clock (often on the town hall) based on solar noon. It's the railroads that demanded time zones to make their scheduling easier.
Tell that to China, where there is one time zone for the country (when by geography there would probably be three or four for an east-west oriented country like it is). Yes, the official time is far closer to solar in Beijing than it is in Urumqi, but it is hardly unworkable.
China is the proof that it's unworkable! In Xinjiang, even though everyone is "officially" on BJT, lots of shops publish hours in local solar time and that's what a lot of people use for their actual lives. If an authoritarian government can't make people use time that's three hours out of sync with the sun, what hope is there to get liberal democracies to get people using time that's eight, nine, ten hours out of sync? It will just mean everyone uses informal local time standards, and now instead of making things simpler you've blown up the complexity by orders of magnitude.
It doesn't really work in China though. It seems to because so much of the population is along the coast and roughly aligned with the enforced time but you see people deviating from the official time in the West where the desync becomes obnoxious.
Most commentators, especially on HN, live in latitudes close to the equator (say south of 55N)
Sunrise in Glasgow if the U.K. was on UTC+1 year round would be as late as 0945 in December, civil twilight wouldn’t start until an hour after people leave for school.
I'm not sure what is the argument here. That car crashes meaningfully rise when people drive in the dark? That's possible, but car crashes and other fatalities increase after the time shift in both directions. The problem is the confusion and the disruption in sleep patterns, not the light levels.
Also in Scotland - I'm quite happy with the current arrangement - it means mornings aren't too bad in winter (going to and returning from work in the dark would be miserable) and it means we get glorious light evenings in summer.
It's a bullshit argument. With time zones, in some countries it's perfectly acceptable to call at 7:30 AM, and in other countries that's way too early. How are you supposed to know? Maybe the person you're calling is an early bird, maybe they're a night owl. You want to call a business - maybe they're open on Sunday, maybe not. Who knows when an appropriate time to call is?
Easy. Without time zones, you post the hours (UTC) when you're available. You refuse to answer the phone outside those hours. UTC makes this easy!
I sometimes ask an interview question: can you think of any situations in which it's not appropriate to store a date and/or time as UTC?
Most eggheads, including many senior engineers, will think for a bit and eventually say no. It's beyond dogma at this point that storing localtime is bad mmmkay.
The one exception I've encountered (I suppose there could be others) is when the value is to be used for recurring event scheduling and you need it to happen at a certain time locally. For example, this event should fire at 1am Central Time every other Tuesday morning. Since "Central Time" obeys Daylight Savings, the time component of the UTC representation of "1am" will lose and gain back an hour as the months of the year go by. So instead you would store "1am Central Time" as the scheduled time and fire the job whenever it's currently 1am Central Time.
** If I've overlooked a way to accomplish this with UTC, I'm all ears. I suppose you could have a job that predicts upcoming event fire times and stores them as UTC. For example, "next fire time" could be generated right after the event fires, as the UTC representation of 1am Central Time two Tuesdays from now.
It isn't even recurring events. If event is happening at 8am local time, it should happen at that time even if they change time zone. Which may happen if get rid or keep DST.
There is a distinction between timestamps, for exact moments, and event times, for future local times. The former should be stored in UTC, and the latter in local times.
I don't hate time zones because I have to deal with them in software - there's libraries for that. I hate time zones because I have to deal with people, who never talk in GMT and rarely specify whose time zone they're referring to when scheduling something and don't know if they're currently in DST or not.
"I still don't know if I can call my uncle, though!"
My grammar teach would have comments. "Why are you unable to call him? Are you physically unable? Is the phone not working?" Of course you can call, it's more of a good question on how convenient it is for the uncle to receive your call.
I hated those teachers. Okay, hated is a strong word, but I really liked them much less after banging on such stupid method of teaching. I'm clearly affected by it to this day
This article was written in 2015, when it was already extremely easy to search "What time does the work day start in Australia?". It's only gotten easier and easier as search engines implement smart widgets, of course, but even then it was not at all the medieval process described. (Finding a webcam in the city? As clever as it is stupid.)
> "It would be neat if there was a lookup table for that kind of thing."
There is now and always would be without timezones. Abolishing timezones doesn't mean people stop caring about time.