Timezones are fairly simple to handle, it's Daylight Saving Time that brings an inordinate amount of difficulty. Some timezones observe DST, some do not. The switchover to/from DST is at different dates for different timezones - often even different dates for different years in the same timezone! DST makes date/time calculations extremely difficult and error prone. Eliminating DST would be a huge step to bringing some level of normalcy back to time.
Leap seconds only really affect people making computerized timekeeping systems, satellites, etc. They don't affect the majority of the world's day-to-day. For the most part, only a few specialists need to deal with leap seconds, so no: Daylight savings is a lot more work to deal with.
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.
This kind of thing isn't even that rare, if you look historically and even applies to whole days.
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....
These things come up in computing circles on a regular basis
"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?
When a system becomes so complicated that you find it difficult to express logically in the context of a machine built to run on logic, I think it's fair to say that system has some flaws.
So we all shift to a single glorious time zone to solve all the author's pains. You still need to remember "zones".
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.
> 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.
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.
It would probably be a bit simpler to remember that California is 8 hours behind London than to remember their work schedule is 4pm to midnight( oh wait, 12am is no longer midnight)
This is stupid. While true we didn't have time zones per se until fairly recently, it was worse... Basically noon was when the sun was directly south, which means one town away might be five minutes off.
I agree it's stupid. Just as stupid as the harebrained proposals that occasionally pop up to divide a day into perhaps 10,000 seconds. Or to throw out our current calendar and maybe have 10 months of 36 days with 5 extra holidays a year. Etc.
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.
> As an alternative, wake me up when the USA goes completely metric.
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.
No; this isn't a good idea. The developers on our team live in 3 different time zones (this number has been as high as 6 in the past), so I have some experience in this.
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.
Yup; it's not impossible; but think of how much more complicated the interface would become. There would have to be a whole lot of little, wordy labels instead of simply showing the time.
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?
A "9-5 job" would become... what? A "most common workday start time to most common workday end time job"?
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.
Can you give some examples of parts of the world that have different standard business hours from 9 to 5?
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.
>Yup; it's not impossible; but think of how much more complicated the interface would become. There would have to be a whole lot of little, wordy labels instead of simply showing the time.
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...
> Or, you know, it would just be something like "+6" (meaning 6 hours ahead of your time in their daily cycle), etc.
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.
>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.
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.
> Times have meanings that would be quite difficult to track without the reference points.
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.
It's not arrogant to know there's a "most common" time for meals, working, and sleeping. When you're actually setting up a specific event, of course everyone will participate ("actually, a 7am call is great for me -- I work early"), but knowing the defaults saves a lot of time.
No, you'll just have the ever-present mental baggage of knowing that "today" lasts until about the first tea break at work, at which point we flip the calendar over to "tomorrow".
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.
> 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.
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.
There are definitely inconveniences with timezones (believe me, I know); but this would be worse.
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.
Timezones in computing are an annoyance to solve properly, once, and then always use that code.
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.
Even then, you can make a good approximation to their actual timezone using IP geolocation. Then there are the pseudo-dropdowns where the user starts typing their city name (or a prominent city in their timezone) and you look it up on the fly. And then you package that control up as a module to share with other projects that you write :)
Spoken like someone who doesn't understand the complexity and untrustiness of NTP and time synchronization, and is naive enough to think setting the computer to UTC is the end of the story...
> 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.
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.
You could use a calendar that is aware of timezones, and then you and your contact both see the meeting time as local time rather than someone else's timezone.
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.
> 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."
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.
> 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.
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
Exactly. Almost all of the problems people raise with this way of working are valid problems and can be solved with appropriate tools. Something that can't be solved with tools is for me to have no idea when someone says they want to meet at a particular time whether they're talking my time, their time or some other time.
One problem is that people (and even software) often don't include timezones. By having none, you always now what time they mean.
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).
>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.
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).
> 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).
Interesting article, but a bit far fetched. You can sync your clocks to GMT, nothing stopping you do that. But I doubt you will convince anyone else to. And what about daylight saving time? As much as I hate daylight saving, its still a custom that is used in many parts of the world. There was no mention of this in your article. In the end of the day, we are all quite used to syncing our clocks relative to sunrise. 9am means the same thing where ever you are in the world. So in some ways time zone keeps us all in reasonably in sync to sunrise
>Interesting article, but a bit far fetched. You can sync your clocks to GMT, nothing stopping you do that. But I doubt you will convince anyone else to.
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 you move to one time zone, dates get complicated as well. You may have meetings scheduled on separate dates but in the same business day. Birthdays: they're now the afternoon of one day and the morning of the next.
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).
> 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."
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.
Funnily, before clicking on this link, I was expecting that the author would suggest that instead of discrete time zones we should have continuous ones, e.g., no matter where you are, it's always noon when the sun is highest. You know, just like it used to be pre modern times, and I was kinda curious how the author thinks he could pull something like that off in a completely different society.
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.
This proposal reminds me of the people that want to redo the world's calendar (every year still has 365 days, but each Jan 1st is always Monday, for example).
Changing something as deeply ingrained as time simply isn't going to happen anytime soon.
It's like the college kid sitting around with his buds in the dorm room, smoking a little weed: "dude, did you ever think that maybe what I see as 'blue' is different than what you see as 'blue'?" Most of us soon find out that we're not the first to think of it (not even close), and we also quickly figure out why you'd have to be stoned on bud to think that's a deep thought.
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.
>and we also quickly figure out why you'd have to be stoned on bud to think that's a deep thought.
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.
Yeah, changing date when everyone is sleeping is a horrible backward idea, I want my days to change randomly in the middle of daylight.
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.
This is the issue where it really falls apart for me. As someone who regularly stays up until 2 or 3 or 5 am even now, I'm well aware of the careful phrasing that is required if I send an email in the wee hours referring to upcoming events---"today" and "tomorrow" are to be avoided, or clarified. Probably most of the people here have had to be careful about this at some point. But, it's a reasonably constrained problem, as it currently stands; at least we don't generally have to deal with events that cross the date boundary.
If that date transition happened in the middle of the bulk of daytime events, though....
It only "works" because China doesn't give a shit what people living in the western part of the country (i.e. Uighurs and Tibetans) think about this issue.
66 comments
[ 4.3 ms ] story [ 92.5 ms ] threadI 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
"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?
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.
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.
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).
http://kybernetikos.github.io/UIT
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...
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.
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.
Changing something as deeply ingrained as time simply isn't going to happen anytime soon.
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.
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....
[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.
[1] http://www.swatch.com/zz_en/internettime/
If the idea has any merit, people will go with your superior plan :)