Hacker News new | past | comments | ask | show | jobs | submit login
Time Zones Aren’t Offsets – Offsets Aren’t Time Zones (atomicobject.com)
87 points by ingve on July 6, 2016 | hide | past | web | favorite | 84 comments

I found it amusing to learn about the Australian time zones: Australia is basically divided into three parts, which could be very nicely +8, +9 and +10, except it is +8, +9:30 and +10. OK. Except that in the south, two of the three zones are split and do DST, which the north does not do, so you get +8, +10:30 and +11 in summer in the south (but the north keeps +8, +9:30 and +10).

Now, that was my amusement for a couple of years.

Then I learned that there is Broken Hill, which follows a time zone different from the surrounding area because of the train track history. And there is Lord Howe Islands, which uses a +0:30 minute DST shift instead of an hour.

And then I learned that history also experimented with 20 minute and 15 minute DST shifts, and that double DST (or Hochsommerzeit in Germany) was quite common, too.

You can probably go on and on and on as you dig deeper, and at some point, anyone's mind will blow, I guess.

Another real complexity was parts of Indiana, part of which is in Central, the rest in Eastern. At some point in the past, daylight savings time was chosen by county, and not well recorded. Thus, it is apparently difficult to precisely date local events. It may have also been that the dates of shifting to DST varied as well.

Why is it amusing? Australian states can be quite large and this allows all of South Australia to share a common time, even though they span two (arbitrary) "time zones". India does the same.

Russia tried to do what China does (one TZ) but it is pretty hard -- people like to be awake when the sun is up.

"I want to wake up when the sun is up" doesn't conflict with single time zones, as any resident of western Xinjiang can attest, but since it requires that people get up at numerically earlier or later times, it does conflict with "I want to wake up at 5-9am."

It does conflict, if you have to do business with people in the other end of the timezone.

Alaska used to have four time zones. The panhandle in Southeast was on Pacific (UTC-8), some portions of eastern Alaska were on Yukon (UTC-9), central Alaska was on Alaska-Hawaii (UTC-10), and western Alaska and the Aleutians were on Bering (UTC-11).

Now it's down to 2. Most of Alaska has been placed in the Alaska zone (UTC-9...the former Yukon zone, renamed because Yukon itself (in Canada) moved to Pacific at some point) and the extreme western Aleutians are on Hawaii-Aleutian time (UTC-10).

This posed some hardship, since most of the state is at least one hour earlier than its "natural" time (in some cases, two or more) but has the advantage of reducing the time offset between Alaska and the Lower 48. A mitigating factor is that due to the high latitude the sun's position and clock time have only a loose relationship anyway for much of the year.

> Russia tried to do what China does (one TZ) but it is pretty hard -- people like to be awake when the sun is up.

People can easily be awake when the sun is up by changing their schedule. I've never been to China, but I guess in Ürümqi (today's sunrise: 6:35, sunset: 21:54) and Beijing (4:53-19:46) they adapt their schedule to the daylight hours.

A nice tool to check daylight hours through the year: http://www.timeanddate.com/sun/china/beijing

Sorry for the confusion; I don't find it amusing at all for the size, but for the irregularities.

DST becomes less fun in the tropics.

Longreach is about the same longitude as Melbourne - but compare the daylight hours:

http://www.timeanddate.com/sun/australia/melbourne http://www.timeanddate.com/sun/australia/longreach

You forgot the Australian timezone of Eucla, which is on +08:45. Yes, they have a 45-min offset, for a small town that just has to be different...

Computerphile did an excellent overview of time zones and all their complexities in the context of programming:


I was quite surprised by some of the stranger rules out there, especially the regions that chose to skip a day for whatever reason. Timezones are complex! Far, far more complex than simple offsets.

I changed all my clocks awhile ago to UTC 24 hour. My life is 0 to 23 as it should be. An hour is an array index between that range. UTC is the standard. Standards are great. Like headphone jacks. Imagine (john lennon voice) everyone living this way. Stop thinking your 23 must be night time and my 7 must be start of day. They are just numbers. It's 20 right now. What does 20 mean? Nothing, it's just a pointer.

I used to be firmly in your camp, and then I read this: https://qntm.org/abolish

For the tl;dr crowd, pulled from that article (although I highly recommend you just read it):

Abolishing time zones brings many benefits, I hope. It also:

- 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

- convolutes timetables, where present

- means "days" are no longer the same as "days"

- complicates both secular and religious law

- is a staggering inconvenience for a minimum of five billion people

- makes it near-impossible to reason about time in other parts of the world

- 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

- is not simpler.

As long as humans live in more than one part of the world, solar time is always going to be subjective. Abolishing time zones only exacerbates this problem.

The true tl;dr is this: hours are meta-information. Just like 5am is very early in every time zone, 11pm is late. We expect businesses to be open from 8-11 to 16-19, just like we expect everybody to be awake between 11-21.

Now, remove that bit of metadata and we need to figure out how to encode/transmit it again. At the end of the day, we just recreate time zones, with the added downside of removing a common language we have while traveling - Visit SF from the UK and not only are you jetlagged, but you need to remember that every time of the day you're used to needs to be shifted by 8 hours. - and just... talking to people in other time zones.

Right now, if you post a story on HN about needing to get up for work at 4:30am, everybody will understand: this person gets up for work really early! Move to UTC and it means nothing.

We already have "before sunrise" and "middle of the night" and "after dark" and sunrise and sunset and so on. Most of the time, there's little or no gain from attaching a number instead of using one of those.

(I'm not arguing in favor of switching, just pointing out that we already have the descriptions for times of day)

Depending on the latitude sunset might be when people just start to get off work, or it might be well after dinner. Times have more semantic meaning than just the position of the sun.

None of those are as exact as a specific time. Each of those phrases could be hours long. When you say before sunrise, did you mean 7:00 AM because it's the middle of winter or did you mean 4:00 AM because it's the middle of summer? I live at 37 degrees latitude, less than halfway to the north pole from the equator. It gets dark before 5 in the winter and after 9 in the summer. That's a 4 hours swing, and I'm not even at a very high latitude.

My point was that conversationally, "the middle of the night" gets the point across that you got up early. It wouldn't even matter if the sun were up, it would still get the point across fine.

Pedants that were concerned about the fuzziness of such words could hound the speaker for UTC.

It doesn't. To me, "middle of the night" means midnight to one am. If you meant like 3 am to catch a red eye flight, then I've misunderstood you.

Languages almost always find ways to fill in gaps of how to express something. Often through the form of shared knowledge or idioms.

"I woke up a few hours before the roosters' crow to catch a flight."

It would be awkward to say that today, but potentially less so in some alternate-dimension universal time zone world where it could be a common idiom for "wee hours of the morning". Hours would still have meaning, people at least have the thought that "roosters crow at sunrise". So you got up a few hours before sunrise, whenever that time was.

i think it would be a cool culture thing to be like well i get up at 23 every morning at sunrise. What 0-23 index is your sunrise? Oh sunrise is 13 for you? How cool!

> As long as humans live in more than one part of the world, solar time is always going to be subjective. Abolishing time zones only exacerbates this problem.

Time zones are a great example of complexity intrinsic to the problem. You can't get rid of such complexity, just move it around (or alternatively make your solution less useful).

Getting rid of time zones does simplify time calculations for a computer. But it increases complexity elsewhere and makes computers less useful.

There is a gap in reasoning here. Prior to timezones, all localities had their own time, and it was generally based on solar time. Thus, abolishing time zones could mean going back to local solar time, but the article presumes that this means going to UTC. (Whether it is UT1 or UT2, it doesn't say).

This isn't all that complicated. Pick some astronomically-based event, say when the sun is at the zenith on equinox, and tie local time to that. Then, given that you have coordinates for every significant place on earth, it is an easy computer calculation to calculate the delta of time to where your uncle was sleeping.

Similarly, the offset to UTC is trivially available.

This is a calculation that ham radio operators, among others, already use to know what UTC the sunset or sunrise is (these are interesting times due to ionosphere changes around those times) at some random distant place far away, say Vanuatu.

you might have a point (or two haha) but all I can say is try it. Goto UTC and see how you like/hate it. Also what if not everyone did this but every programmer the world over did this. It would be such a wonderful programmer bonding thing where if you are a serious developer, you live in your life in UTC 24.

Timezones are useful because they let us answer the question "what point in the day is it at <location>." People's schedules are more or less aligned around local sunrise and sunset so knowing what time of day it is at a location important when communicating with people in that location. See https://qntm.org/abolish

China already tried getting rid of time zones, and even though it's only 5 time zones wide it caused enough issues that far western provinces use their own unofficial local time: http://www.theatlantic.com/china/archive/2013/11/china-only-...

Alternatively we could go back to the old approach from before time zones and make 12:00 PM wherever you are be the time at which the sun is at its zenith that day. It's obviously kind of silly but could actually work now that many people tell time with GPS linked devices.

Alternatively to that alternative approach, instead of making local noon be the anchor point, make local sunrise the anchor point: the sun rises at 6 AM.

Note that this has the side effect of automatically making it so the extra daylight during times of the year with more daylight come at the end of the working day, without the need for daylight savings time.

Do you know why we invented time zones?

Train crashes.


Trains presented the first time that 1) humans could travel at a sustained rate above about 10 mph, and 2) presented roadways on which it wasn't possible to spot oncoming traffic and decide, at any point, to simply pull to the side to let it pass.

There was also the matter of coordinating service with local pick-up and drop-off, and whatnot.

So now you had a requirement for all points along a linear track to actually agree on the answer to the question "what time is it now?"

"Local noon" was no longer an adequate solution, or at least, it wasn't adequate with the means available at the time for computing offsets between your local noon, my local noon, and Train Time.

Railroad engineers (train drivers), track switching controls, and other elements also had to be, or could be, coordinated. Uncoordinated switching leads to packet collisions, or in this case, literal train wrecks. Which are messy, bad publicity, and discourage business.

Hourly offsets were reasonably close to solar time (generally no more than 30 minutes off), and abstracted enough complexity that offsets could be calculated (a given train was unlikely to cross two time zones in a day).

This happened in 1883.


I'd like to see something to drive the adoption of 'local relative' offsets.

It has to be better than 9am is breakfast, noon is lunch, and 6pm is dinner; in that it has to be short and memorable.

The time of an event that happened needs to just be UTC; period.

The time that something is planned might not be an event, but could be a relative reference.

"local relative"

What does that even mean?

You realize this doesn't actually effect anything except making you and anyone you interact with have to do the mental math for the correct offset?

The only reason to use UTC is so you can compare timing of geographically diverse events easily (plus things like daylight savings). Local time is still local tmie.

For recording events that happened, sure. For future events (eg. meetings at 10am every Tuesday), unfortunately we still need to deal with timezones...

no that kind of thinking is what causes world wars! Everyone can agree on 0 to 23 the whole world over and make that "Tuesday 10am" meeting.

What does "am" mean?

No, the idea is that everyone uses UTC. There is no benefit to individual timezones.

Then everyone outside the tropics has to adjust their daily schedule as the seasons change. Measured time is a tool that exists for the convenience of man not computers or their programmers.

I agree. Also swatch tried this. The respective watch still resides in my collection. Swatch beat (or was it beep) decided the day into 1000 pieces and had no timezones.

Clearly it worked and no one uses the old system anymore. <irony off>

For me timezones are OK. They are a cultural construct developed to accommodate the custom of counting the hours from sunrise (later midnight) and higher numbers meaning later in the day.

Not every sociocultural construct is bad just because it causes us code monkeys some trouble.

And believe me. Trouble it causes day in day out to me.

Ah the Swatch Internet Time https://en.wikipedia.org/wiki/Swatch_Internet_Time ... I remember implementing this for a local BBS, nobody could figure out how it worked.

They arrogantly based it on UTC+1. Might have been useful of it was sane

Yes, because UTC itself is a non-arrogant, sane default. Clearly the Royal Observatory in Greenwich is the center of the Earth and always will be.~

but try living UTC 24 yourself. Change all your own clocks. I did awhile ago and I'll never go back even though I live in Los Angeles. Everyone can do this as well and be liberated from time.

Ironically, your experiment worked only because all the adopters (that is, you) lived in a single time-zone, neatly sidestepping the entire problem timezones were meant to solve.

Do you have any meetings / conversations with people in other time zones? Particularly ones further away like say London or Sydney? It's easy enough to remember +-3 within the US because we shift in unison (and your choice of UTC just means you'd memorize a different offset when someone says "10 AM Pacific") but interacting across real changes in time is hard. Unless you get everyone to use the same inputs, you're going to do this translation on all correspondence.

So how do you live? ;)

This doesn't make any sense.

Minor: Los Angeles doesn't have a constant offset to UTC. But it changes rarely enough that it's easy to absorb the inconvenience.

Major: if he was using Los Angeles time internally, he'd have all the same problems when interacting with anyone else. Using UTC internally, he still has those for counterparties that don't use UTC, but they disappear for counterparties that also use UTC. Using UTC is a strict upgrade in terms of interacting across "real changes in time".

When I interact with people in a different time zone, I like to use their time, because I figure the odds of them messing up when using their own time are low. But if I didn't do that, I seriously doubt they would have more difficulty with my proposal "let's meet at 04:00 UTC" than with my proposal "let's meet at 12:00 pm my local time".

I convert back to LA time when I need to. It's fun math that keeps me sharp and helps me always program timezone aware apps because I'm always thinking about two different timezones.

Why would translation be difficult? It's just adding small integers to another small integer.

I use times to coordinate with other people. How do you accomplish this coordination?

u think 7 implies light? And 22 implies dark? Or vice versa? They are just numbers!

Haha, I have this sign [0] hanging in my work area along with a number of other TZ-related quick-reference documents. After getting burned badly by pre-existing code that assumed America/Mexico_City was the same as America/Chicago (As in both were "Central" and had offsets of -6/-5). While they have the same offsets they change between DT/ST 2 weeks apart. I learned of all of this less than 2 weeks out from the change...

[0] https://www.dropbox.com/s/kwiddhvbj24th0s/2016-07-06%2015.56...

It's so much more pleasant to deal with datetimes and timezones when you have a good API that doesn't muddle and mix concepts for you. The Java 8 time API [1] stands out, which was co-authored by Stephen Colebourne of Joda-Time fame [2].

[1] https://docs.oracle.com/javase/8/docs/api/java/time/package-...

[2] http://www.joda.org/joda-time/

Related and previously discussed: Falsehoods programmers believe about time and time zones [1]

[1] https://news.ycombinator.com/item?id=11515125

My mind was blown a while back when I learned that there are timezones with offsets that are not whole hours. E.g. Kathmandu is +05:45.

Anyone who's lived in Canada for any period of time is almost immediate bombarded with this reminder. Newfoundland (eastern-most province) is half an hour off so most television shows must convey this through a mantra like: "Tonight at 6pm (6:30pm in Newfoundland)".


The Saudi government was considering running the really big clock (46 meter diameter) in Mecca [1] on local solar time. The goal was to run the entire Islamic world on Mecca time.[2] But it didn't happen.

[1] https://en.wikipedia.org/wiki/Abraj_Al_Bait [2] http://www.telegraph.co.uk/news/worldnews/middleeast/saudiar...

All of China (the size of the US) operates on Beijing (east coast) time.

They're not even all in "exotic" locations:


This is why RFC 3339 (and ISO 8601 before it) doesn't allow you to do -07 as an offset, you must specify the whole damn thing (even though so many are whole hours).

Even more amusingly, thanks to the old "noon is when the sun is at its zenith", there are historical time zones that aren't representable as whole minute offsets from UTC either.

> there are historical time zones that aren't representable as whole minute offsets from UTC either.

Luckily we ditched all of those before we invented leap seconds.

How about that Timezone with offset +13 hours.

So much crazyness in the world of Timezones.

Or Morroco Timezone which does the DST dance 4 times a year rather than just 2.

As someone who recently had to implement time zone (offset) preferences in a web app to satisfy a "Daily Requirements" feature...

I just wanted to say that I hate time zones with a passion.

This is the correct feeling

Which you'll be reminded of again when DST rolls around.

To me, one of biggest culprits of DST is also the reason why offsets and timezones aren't in 1:1 relationships. The arbitrary mandates of time changes from all levels of local/state/nation governments had made it a big mess in figuring out local times. Time should be continuous in nature. But it's not when you apply all these manmade rules.

Here is the table[1] of most but probably incomplete rules.

[1]: https://en.wikipedia.org/wiki/Daylight_saving_time_by_countr...

DST is an issue, as is the political selection of time zones. There's a great map[1] that shows how arbitrary time zone shifts are.

Even in the EU, the eastern edge of Finland is over an hour east of the center of CET, while western Spain is two hours west of it. That means that during the spring and autumn solstice, even though we have 12 hours of day and 12 hours of night, the sun over western Spain sets three hours after eastern Norway. For Norway it makes sense, most of its people live smack in CET, but for Spain it's a purely political gesture.

[1] http://blog.poormansmath.net/how-much-is-time-wrong-around-t...

I had an unusual timezone related bug.

I was adding "Night mode" to Nova Launcher, allowing a dark theme to be applied after sunset. To accurately calculate sunrise/sunset the location permission is required, but that's the only thing Nova Launcher needs the permission for, and only Android 6.0+ has runtime (optional) permissions so I didn't want to force the permission on everybody and needed a fallback.

I knew that time zones aren't offsets but locations (ish) and for calculating sunrise/sunset they should be close enough. Nova pulls the device's time zone (something like America/Chicago ), maps it to a lat/long, and calculates the sunrise/sunset. It just depends on how accurate the timezone data is.

Public beta went fine, but stable release we start getting a small, but concerning, amount of emails from people saying that their icons won't load, or disappear, after the update. We're asking for information trying to find a pattern, but it's across different Android versions and devices. Finally we notice all the carriers are Canadian. Then it gets more specific, it's Winnipeg (turned out it was actually Manitoba, the province Winnipeg is in). First thing I test is setting my device timezone to America/Winnipeg, but everything works fine for me. We're getting some more device information from the reporters, and their timezone isn't America/Winnipeg. but America/Resolute. That must be close to Winnipeg right? https://goo.gl/maps/E5vj5nHfJgu Notice how far north it is. https://www.timeanddate.com/astronomy/canada/resolute And the sunrise/sunset times, or lack thereof...

I actually anticipated this, and there was some code to just use hard coded times for cities too far north to have a sane sunrise/sunset. However either that code broke later, or it only worked with GPS coordinates, and I assumed all the timezones were safe.

I don't know why carriers in Winnipeg report the timezone as Resolute, but the fix came in two stages. 1) Properly handle locations that don't have sane sunrise/sunset times. and 2) Treat America/Resolute as America/Winnipeg

The programming mistakes people make relating to time are legion. I feel like time/date, floating point and crypto are areas where nearly everyone (not just programmers) would hugely benefit by coders only using libraries written by the very few who are actually competent to write them[1].

And anyone who thinks they are qualified to write time related code by virtue of having coexisted with clocks and time definitely should not be writing time related code.

[1] Time handling is different than FP and crypto, in that most of the complexity is human-created and policy driven rather than deep math, but for whatever reason people really don't understand that time handling is very complex - it seems to be widespread Dunning-Kruger. So they repeatedly make bad mistakes with very strange-seeming trigger conditions that can't be debugged on demand until someone realizes it is a time related bug.

That linked story about Michigan's -5:32:11 offset is hilarious https://github.com/eggert/tz/blob/master/northamerica#L979

I, for one, have enjoyed seeing this piece of content marketing on top of HN, and will be buying this company's products and services. Good to see something other than the Macro up here.

Did the author just collect a bunch of random bits of information from Wikipedia and attempt to construct a thesis around it, or is there a point to this article that I'm missing?

When you select your "timezone" in a web application, you usually get a list of offsets instead. If you live in a town which falls in an offset but the timezone isn't consistent, then your time will not be correct at certain parts of the year.

It is important to understand the difference so you can build a time system that works for everyone, not just the majority.

I'm increasingly becoming convinced that there is no reasonable way to build a time system that works everywhere. It's ridiculously complicated.

I think I would agree with you. It's definitely tricky.

I don't think this has been true for a while now. For example, the most common timezone picker I see has multiple timezones listed per offset. Here's some examples:




Fond memories of Travian games here. Log into enemy account via a super dodgy sitting arrangement, send a confusing message about the time of an attack and watch chaos unfold as other players in the alliance screw up the offset they were aiming for and leaning early or late. Even when no shenanigans were played there was a 50/50 chance that someone would mess it up.

Uh. Eastern, Mountain, Atlantic, etc. are actual official time zones. America/Detroit does not appear to be such.

Devney mentions that she is focusing only on IANA timezones. See a list here https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

America/Detroit is a valid IANA timezone. Eastern is not.

Edit: Etzos has pointed out that US/Eastern is on the list. Thanks for correction.

Ah. I missed that while skimming through the page. I was primarily responding to the statement made that "they are also called “time zones” in casual conversation." They are time zones in the official sense of the word.

Speaking as if the Olson tz database is authoritative and official reminds me of when some small country cancelled summer time with only a few days notice and our OS vendors were not going to be putting out a patch in time. While explaining the process of downloading the Olson tz database and updating systems manually, a coworker asked who gave them (the country's government) permission to cancel DST. It took longer than it should have for me to come up with an explanation that sovereign countries don't need permission from the Internet or OS vendors to change their laws and regulations. The computers track the government actions, not the other way around.

  > some small country cancelled summer time with only a few days notice
Egypt just did that.

- In April, Egypt announced daylight time would start July 7. http://english.ahram.org.eg/NewsContent/1/0/204655/Egypt/0/D...

- On June 30, Egypt decided daylight time would start July 5. http://english.ahram.org.eg/NewsContent/1/64/232199/Egypt/Po...

- On July 4, Egypt decided not to have daylight time. http://english.ahram.org.eg/NewsContent/1/64/232478/Egypt/Po...

While you're right that countries don't need permission to change their timekeeping, they should be fully informed of the technical trouble they're creating when they make changes.

You'll notice that list includes US/Eastern which links to America/New_York as the correct "standard" for that timezone.

Edit: Just want to clarify that "Eastern" and others are indeed on that list and everywhere I've needed them have worked in place of the physical location equivalent. The physical locations, however, are the standard for the respective timezones--I am not commenting on the correctness of the GP post.

Thank you, I missed that. I have noted your correction in my comment.

If it helps, you can think of the IANA time zones as functions from UTC to local time. This is not quite the same as the political definition. For instance, both America/Boise and America/Phoenix are in the "Mountain time zone". But when viewed as functions, they're very different -- one is continuous and the other is not.

To add another layer of complexity, the tz database is capable of representing time zones whose definitions are themselves changing over time. If your state government decides to switch from Eastern to Central time next year, you still want to be able to accurately answer questions like "what was the current local time in this location at UTC instant t?".

Eastern Standard Time is an offset -5:00, not a time zone. Eastern Daylight Time is a different offset -4:00 that is used in many of the same time zones as EST, at different times of year.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact