The case against time zones: They're impractical and outdated
vox.com
vox.com
Times have meanings that would be quite difficult to track without the reference points.
I'd be happy if daylight savings were gone -- that's much more cost than it's worth. But even if it were possible to switch everyone to UTC, it'd be awful.
Let's say you're in SF and you want to schedule a conference call with someone in Bangalore. You'll use worldtimebuddy.com or similar to compare your day with theirs, and you'll find that your first thought, 2pm, is 2:30am in Bangalore. So... maybe you can get up early -- 7am for you is 7:30pm for them. Better ask if maybe they'd prefer to meet after dinner, or (since you stay up late) perhaps YOU could call after your dinner and catch them at 9am Bangalore time... that's when the most common working day starts.
Think about doing this check without timezones. 2pm for you is... 2pm for them! How useless to know that. So you'll still need some reference to figure out when they will probably start their workday, when they'll probably break for lunch or go home for dinner, etc.. But how can you refer to those times sensibly without using times? You'll say "oh, so 2pm for YOU is sort of like 2 AM for me, how awful that I called your mobile then". And boom, you've re-invented timezones.
Times (with shared meanings) are good shorthand. If we discard the shared meanings, we'll need something else to replace them when we're talking to people outside our part of the world (which, of course, is happening more & more).
A "9-5 job" would become... what? A "most common workday start time to most common workday end time job"?
"I was up coding last night until 3am" would have to be something like "I was up coding last night until 6 hours before the next day's standard workday start".
["Until 3 hours before dawn" was my first thought, but that's not very meaningful -- staying up until 3am is pretty much the same even though the sunup time may vary widely depending on location and time of year...]
If you're talking to someone who lives in Barcelona, and you say "oh, I should probably let you go -- is it almost dinner time?" -- because it's 6pm in CET -- she may respond "oh, no -- most people here don't have dinner until 9 or 10pm". That's interesting, right? But how do you even have that conversation without sharing a time/meaning shorthand?
It'd become the same as in any country which doesn't have that particular expression, that is, probably most of them.
"I was up coding last night until 3am" would have to be something like "I was up coding last night until 6 hours before the next day's standard workday start".
There's no such standard; different countries have different business hours, so to a foreigner "3am" doesn't tell her that it's "6 hours before the next day's standard workday start", and to a local you can just say the actual time, since she would know the new "standard", whatever it'd be.
In your explanation, don't use times as reference points.
...
Yes, of course there are variations in standards; but that makes times all the more valuable as reference points. People in Saudi Arabia, for example, will have similar ideas of "what people do" around 6pm, and if they work with someone in Argentina, they can have an interesting conversation figuring out how Argentinians are different (and how they're the same). But if they lose time as a shorthand, it's suddenly really hard to have that conversation.
Or, you know, it would just be something like "+6" (meaning 6 hours ahead of your time in their daily cycle), etc.
I mean, it's like a lot of people commenting against this hasn't paid any thought to it at all...
That's re-inventing time zones for this timezone-free world, though, isn't it?
The problem is that timezones would still exist (as you point out -- that +6 must come from somewhere...), but because they would be unofficial and no longer standardized, it would be harder to know.
Every city would need to figure out "standard business hours" somehow -- because an awful lot of businesses talk to each other during their working hours. Neighboring cities would need to coordinate, somehow. But how would worldtimebuddy know whether to display "+6" or "+7" for a given city?
They can't just guess it on sun cycles; sunset in London varies from 4 pm to 9:30 pm, and of course some people live further north (or south) than that -- and "working day" hours aren't bound very tightly to sun cycles anyway.
Who said they would be "unofficial and no longer standardized"? They could be both, fully.
We also have the perfectly official and standadized meridians, that are better handled than the ad-hoc timezones we use (that sometimes go over several meridians, use DST etc).
The proposal is about getting rid of timezones in the sense of having a fixed, global time.
Not about getting rid of timezone information completely.
It simplifies tons of everyday interactions and calculations, and when one needs to know the other's "time in the daily cycle", it regresses to exactly knowing the kind of information we need to know now.
Precisely. When's breakfast? About 7 am UTC. And 7 am NZDT. And 7 AM PDT. And so on and so forth.
This proposal only makes sense from the point of a lazy programmer who is arrogant enough to imagine that their local understanding of schedule trumps everyone else's.
The idea that there's a "time for breakfast" (or for working, or for sleeping - my father-in-law in a night guard) is no less arrogant.
If you want to know what time to call someone, how about you ask them?
We'll also know that 12am is noon in England and dawn in New York. We could have handy mappings to look that up too.
We just wont have all the constant need for mental conversion baggage associated with timezones, and the crazy boundary issues.
What an absurd, broken world to live in, just because someone was too lazy to use a calendaring system that was timezone-aware!
Sorry folks, living on a round planet orbiting a star means you have different sleep/wake cycles when compared to a common clock. It's a solved problem, and changing the solution won't make the problem go away.
And then you discover that you misread the direction of the shift and you actually should have arranged in the early morning for you, or you've checked time in that country's capital rather than in the place your contact is, or they thought the time you gave them was in your timezone... and neither of you realize you've fucked up until meeting time.
Without timezones, you look the timezones up and suggest 7pm, but you've shifted the wrong way and that's the middle of the night for them when you thought it was early afternoon? So you say "how about 7pm" and either they say "no, that's the middle of the night, how about 10am", or they just get up in the middle of the night. But either way, that time you've agreed is completely unambiguous for both of you and there's no way for it to go wrong.
The political nightmare of convincing the non-British part of the world that "sorry, your day of the week is going to switch in the middle of the afternoon", for example, hasn't even been mentioned yet. Some of those places might not be keen on having their clocks running on British time. To put it mildly.
And honestly, the inconveniences aren't hard to work around. If you work across timezones, you figure it out pretty quickly.
I work on London time, but live in Central European time; I just talk normally in London time when I'm at work. If we're scheduling something in a timezone-disparate group, I always say "2pm London time" and optionally add in "6:30pm Bangalore time" or whatever is needed. It's only daylight savings that gets annoying, because it changes the offsets.
If I've done this bit of simple arithmetic wrongly -- hey, it can happen -- the problem is revealed when I send out meeting requests. Everyone using standard calendar software on their computers (Outlook, Google calendar, whatever) sees the meeting in their local timezone (because of course meeting requests include tz offset info!), so before they actually accept the meeting request, they'll know I've done it wrongly.
Spoken like someone who has never dealt with computing time.
Use a library of timezones maintained by someone else (in the OS, the VM, or similar), because these need to include the history of timezone changes to be complete, and countries continue to change their timezones, daylight savings rules, etc.. I'd dearly appreciate it if everyone got rid of daylight savings time, but it's abstracted away for almost all applications now.
For most purposes, you can store all times in UTC in the database, and let people choose the timezone they want to use for data entry and display. Sometimes you also need to store the "local time" -- e.g., imagine you'll need to generate reports on some stat between 9am and 10am local time, for locations in many timezones -- but always store UTC first.
Building the dropdown list people will use to choose their timezone is probably the most annoying part of it. It's hard to come with something that's complete without having terrible usability.
If you think timezones are annoying, wait until you discover leap years and leap seconds!
This is the main real objection. My solution for UIT (http://kybernetikos.github.io/UIT) was to have two different kinds of day, the international day, which switches at .0 UIT and goes nullday, unday, duoday, triday, quadday, pentday, hexday, heptday, octday and nonday, and the local day which switches at local solar midnight (modulo DST) and goes sunday, monday, tuesday, wednesday, thursday, friday, saturday. The clockface shows when they both change, so it's not too difficult in use.
Point being, when someone says "Lets meet on IRC at .4:20 21st Nonday" it refers to a particular time in a year anywhere in the world unambiguously (the 219th day of the year, zero indexed).
It's pretty inelegant, but the idea is you would use the local day names when talking to people in the same place as you, and the international days when arranging something with someone physically separated from you.
Without timezones, each person attending the meeting has to do the mental calculation, "04:00UTC is 14:00 my time, so I'll actually be awake for that meeting, and will have to ensure I don't start anything big after lunch." And then you'll make mistakes "12:00? that's fine … oh, it's actually just after midnight my time".
All these arguments about timezone math and "getting the shift the wrong direction" apply to "let's all use UTC". In fact if we all use UTC it makes the problem demonstrably worse: you now have to do the adjustment all the time. No longer does "6pm" mean "close to sunset" for most people. You have to keep a sunset/sunrise calculator with you at all times just so you can remember what time to set that alarm in order to be at the local office on time. Then when you travel between places that will used to have timezones you'll need to adjust your sunset/sunrise calculator. No longer can you simply set the alarm to go off at 6am local time.
You're replacing a superficial problem with an actual one: everyone who doesn't live in the reference time locality will be living on bizarre time.
So how about just using a calendar system that stores information in UTC but presents it in local time, and exchange calendar appointments with your colleagues using this calendaring system so nobody has to do the mental math when transcribing the appointment into their calendar?
My calendar already does this. It's a solved problem, and changing the solution won't make the problem go away.
No you don't. The whole point is there's no "14:00 my time". You just work from 23:00UTC to 08:00UTC and take your lunch at 02:00UTC. All your clocks are UTC.
> No longer does "6pm" mean "close to sunset" for most people. You have to keep a sunset/sunrise calculator with you at all times just so you can remember what time to set that alarm in order to be at the local office on time. Then when you travel between places that will used to have timezones you'll need to adjust your sunset/sunrise calculator. No longer can you simply set the alarm to go off at 6am local time.
True, it makes life harder for people who are physically travelling to a different office every week. But how many is that, compared to the number of people who need to arrange a phone/video call with someone in a different office? And that ratio is only going to push further.
> You're replacing a superficial problem with an actual one: everyone who doesn't live in the reference time locality will be living on bizarre time.
What's the problem? You get up at 01:00, the shops open at 03:00, you go to bed at 19:00 - so what? Ask anyone who lives in Vladivostok.
My one-time-to-rule-them-all does in fact include a sunset/sunrise calculator, which it draws onto the face based on geolocation. http://kybernetikos.github.io/UIT
Knowing the best time to call someone in another area of the world seems like a problem that wouldn't really change, neither for the better nor for the worse; instead of having wordtimebuddy.com tell you the time there, it'd tell you the working hours (eg. 2m - 10am).
With both schemes you need to know that, say "2am here is like 2pm there".
With the proposed scheme, all the other crap that goes with timezones unnecessarily is removed.
Finding when time X (that you have a meeting or an event happens) is at both places? Instant. Knowing time difference when you are given the time at 2 different places? Instant. Time conversions for commerce etc? Done with. How long a flight will take? Instant. Adjusting your watch after arriving somewhere? Done with.
It's the difference between having to do the conversion only when you need it (e.g to know the relative "phase of the sun" at another place) vs having it to do for trivial stuff that doesn't need it, and complicating things needlessly.
(Not to mention: timezones, because they are irregular, and not equal 24 divisions of earth, do not reflect actual "phase of the sun" at place X. With a constant universal time, we could use equal divisions to find out the difference, which would be even more accurate than knowing 2am Bangalore is X am at some other place).
The time system I came up with uses geolocation to orient the clock so local solar midday is always at the top of the clock (12 o'clock on a normal clock) and local solar midnight is always at the bottom of the clock (6 o'clock on a normal clock).
You work in NY and propose a meeting at 1300 GMT? You still need to remember how far ahead London is, how far behind California is. Want to call your cousin in Tokyo? You still need to know when she's likely to be awake. Heading to a vacation and want someone to pick you up from the airport? You need to know if your flight lands in the middle of the night or while your ride is at work.
Sure, you could divide the world up into 24 zones and call it a day. Then people still face the same problem of a strong dividing line separating suburbs and cities. Or a country split between two or three zones when it really only needs one. And then you realize, as a self centered programmer, people aren't robots and local time makes sense for 99.9% of peoples' lives.
But it's a lot easier to see when the appropriate time is if you know London works 8am-4pm GMT and California works 4pm-12am GMT, than trying to remember that they're three hours behind and calculate it every time.
> Heading to a vacation and want someone to pick you up from the airport? You need to know if your flight lands in the middle of the night or while your ride is at work.
If you're talking to them they can presumably tell you. Again, much easier if they know what time they sleep in GMT than if you have to calculate it afresh for each conversation.
> And then you realize, as a self centered programmer, people aren't robots and local time makes sense for 99.9% of peoples' lives.
People in eastern Russia, or western China, already work on a distinctly nonlocal time. It works well; the shops open at whatever time makes sense local time, but when you call someone across the country you can talk about times with them without getting confused.
Furthermore, while travelers may not have to change their wristwatch to account for the local time, they still would have to grasp "what time the locals do X." This may be more difficult for people to reason about if they can't easily draw on their expected scheduling from "back home." Simply knowing that 8:00 to 5:00 is a common work-day will no longer be easily translated, as it may be 11:00-20:00 one place and 05:00-14:00 somewhere else.
In any case, people are creatures of habit, so they tend to fight change. So I don't foresee this ever happening, regardless of whether it would solve some problems (and debatably it may cause as many problems as it solves).
Good point -- everyone is welcome to switch to this system now, when traveling. Just don't reset your watch.
You'll just need to learn the new time to set your alarm in the morning, the new time to say "whoa, we'd better get lunch before restaurants close", the new time to think about getting the kids to bed....
It's so much easier to just reset your watch (or like most people I know, just double-check your phone has auto-updated to the new time zone), and keep your reference points.
We could then invent a new word to differentiate between the "day" as the date and "day" as this daylight cycle. Then we would need seven new week day names to differentiate between the official date and light cycle. Lot of fun in perspective.
But then it would make visiting other countries easier, no need to set my watch... oh... wait I have to change my whole brain to adapt to the new schedule instead.
If that date transition happened in the middle of the bulk of daytime events, though....
I guess you've never had to deal with time zones then.
DST isn't the only thing you need to take into account. You're forgetting that cities, states and countries modify their timezones for political reasons e.g. America/Sitka went from UTC-8 to UTC-9 in 1983. Just to repeat this if it's not clear, that's a UTC offset change for the Sitka zone, not a DST update.
The most extreme example was how the Swedish calendar attempted to swap to the Gregorian calendar:
n November 1699, Sweden decided that, rather than adopting the Gregorian calendar outright, it would gradually approach it over a 40-year period. The plan was to skip all leap days in the period 1700 to 1740. Every fourth year, the gap between the Swedish calendar and the Gregorian would reduce by one day, until they finally lined up in 1740. In the meantime, this calendar would not only not be in line with either of the major alternative calendars, but also the differences between them would change every four years.
In accordance with the plan, February 29 was omitted in 1700, but due to the Great Northern War no further reductions were made in the following years.
In January 1711, King Charles XII declared that Sweden would abandon the calendar, which was not in use by any other nation and had not achieved its objective, in favour of a return to the older Julian calendar. An extra day was added to February in the leap year of 1712, thus giving it a unique 30-day length (February 30).
In 1753, one year later than England and its colonies, Sweden introduced the Gregorian calendar, whereby the leap of 11 days was accomplished in one step, with February 17 being followed by March 1.[1]
So February 30 1712(!) is a valid date in Sweden, but February 17 1753 + 1 day = March 1.
Imagine building something like a utility billing system over a time period like that....
[1] http://en.wikipedia.org/wiki/Swedish_calendar#Solar_calendar
I mentally picture the same thing here. "Dude, instead of all of these time zones that make my work difficult, what if we had one big time zone?" Based on the comments here, most of us have figured out why it's not a brilliant idea, and no, we're not the first to think of it. The author instead wrote a blog post about it.
That's only because most people are like sheep, capable of only thinking of their immediate practical problems.
Far from being just a "stoner discussion", the perception (of color etc) question has been examined in length, both in philosophy and cognitive science, and is as deep as they go indeed.
"Wouldn't it be easier to write my code if I didn't have to deal with time zones?"
All you have to do, of course, is persuade people to change their entire system of local time, which is what they use 99% of the time. How hard can it be?
Instead, his suggestion is pretty much the opposite: instead of discrete time zones, let alone continuous ones, the proposal is to have one static time zone globally. Strange that the headline calls the current system "impractical", as the disadvantages of a single global time zone are kind of obvious (see the comments here on HN).
I suppose, the current system is a good compromise that tries to address the disadvantages of continuous and static models.
Not gonna happen. But the reason it gets talked about at all is because it's something that ordinary people can think about and propose. It's not rocket science.
As an alternative, wake me up when the USA goes completely metric. That's something much more important and useful and still it hasn't happened in my lifetime, even though I was taught metric in school nearly 50 years ago.
Oh, $DEITY, don't get me started on that off-topic topic. All that book learnin' forty years ago and all we got out of it was 2 liter bottles of soda. We don't even get the miles/kilometers signs anymore. At least I rarely have to deal with SAE fasteners these days.
But point taken: we're not getting rid of time zones if the U. S. can't even jump on board on the measurement system used by every other country (yeah I exaggerate a bit, Captain Pedantic) in the world.
[1] http://www.theatlantic.com/china/archive/2013/11/china-only-...
Would be interested to hear how these "wide-zones" work in practice from people who have lived in them for a while.
I don't think it was about "convincing". It was about it happening by decree. You know, just like how the timezones we use were enforced in the first place, or Gregorian calendar, or any other regular time keeping...
If the idea has any merit, people will go with your superior plan :)
Changing something as deeply ingrained as time simply isn't going to happen anytime soon.