> These are the people for whom adjudicating upon such matters as France’s attempted move to the decimal system and the International Atomic Agency’s periodic decision to add nuclear seconds to the world time system are the bread and butter that they grapple with at work every day.
I believe the author is referring to leap seconds? International Atomic Agency is I think jumbling up the International Atomic Energy Agency and International Atomic Time. The agency responsible for leap seconds is the International Earth Rotation and Reference Systems Service (IERS); the IAEA is not involved in timekeeping standards as far as I know.
just as an aside, he's separately and also referring to the deal between UK and France where the French agreed to accept Greenwich being the Prime Meridian in exchange for the UK adopting the metric system.
The importance of the meridians was determined by the publications, e.g. nautical almanacs, which were issued by the astronomical observatories located on those meridians.
Prior to the establishment of a unique origin for meridians, the navigators were divided in those who used nautical almanacs from the Royal Observatory of Greenwich, those who used nautical almanacs from the "Observatoire de Paris" and so on, for almanacs from other less important observatories.
All observatories published coordinates based on their own meridian (which was precisely where their meridian telescope was located).
Holy cow was this unreadable. It kept pulling me in with something I was interested in, then never clearly explaining before jumping to the next thing. I oddly sort of enjoyed the whimsy of the writing, but I came away with essentially no new information.
Nothing does justice to the actual TZ database and the comments within. There is quite a bit of detailed commentary and sourcing for the actual offsets.
Does the article ever return to tell the reader what the timezone community was up in arms about? I gave up finding out, as the article just continued on tangent after tangent.
All I can think of when I see this is the pain of managing timezones in python and then integrating utility energy data that uses their own random skip hours to comp for their terrible data systems.
You have a number: the amount of seconds that have elapsed since some standard moment in time. (Usually the seconds since the start of 1970-01-01, London.)
The have a problem: how do you take this information and use it to render the time on your local time rendering device, in your current legal jurisdiction or place on Earth organized enough to make decisions about time?
tzdata solves this problem.
You’re usually working with a clock with a 12h or 24h output and a minutes output. But what about non-standard time-rendering-devices / wallclocks? Are there cultures that do something different to 24h days, similar to the global diversity in date-rendering?
I guess it's not worth the headache having your own clock if you want to deal with the rest of the world, but in S. Arabia it was once common to set your watch to 6 am at sunrise:
# Unfortunately tzdb records only Western clock time in use in Ethiopia,
# as the tzdb format is not up to properly recording a common Ethiopian
# timekeeping practice that is based on solar time. See:
# Mortada D. If you have a meeting in Ethiopia, you'd better double
# check the time. PRI's The World. 2015-01-30 15:15 -05.
> And here’s something else I learned: Pre-independence Ireland once operated its own time zone — Dublin Time — which was stamped out by the British as punishment for the Easter Rising.
Great text on why it's so difficult to put into code human activities. Do you want a library to deal with complex math equations? No problem, you can define clear unit test that will stand the trial of time. Do you want to code time zones or addresses? Thought luck.
At my first job we had an home made CalDAV server. One feature is the Free/Busy letting people ask for other people availability. Once you try to handle 'exceptions to recurring calendar events with a side of timezones and DST' you know why you should use existing libraries.
I wonder what DST does to data collection such as weather and stuff. just imagine one team collecting data with DST and another without DST and then merging the data.
I don't mean to be rude to the author, but I found this style of writing difficult to read. Too verbose, too full of asides, to focused on himself and not the actual information. Makes getting useful information out of the text needlessly difficult.
I agree, but it was mercifully not full of animated meme GIFs, so I still found it to be relatively pleasant reading. Not everyone's a writing master, and not every writing style is to everyone's taste. On balance I found it worth the read.
Completely agree. It was painful and it was weird the things he explained and the things he didn't. The listserv looks like a listerv. When that isn't going to make any sense to anyone who doesn't knkow what a listerv is.
Then there was the reference to the Hashemite Republic of Jordan. I was like, "is that some breakaway part of Jordan? But no, it just seems like the Hashemites are the royal family? ugh.
I don’t know how everyone else feels, but I would happily have my “‘normal” hours be completely changed if the whole world could just define a single, global time. I’m sure it would be a massive undertaking, but it would make my life so much easier to be able to talk to my globally spread out teammates and never wonder about what time zone they’re referring to, or worry about time conversion when traveling.
You should setup your do no disturb settings so you don't get those when sleeping. You should do this even with timezones still in use. Sleep is important.
Emergency calls from the police, hospital, your father-in-law’s neighbor, or other number not in your contact database are often even more important than sleep.
But the damn robocallers have destroyed the primary use case of telephones. When I was a kid the phone was for “important” stuff, and “tying up the phone” with an unimportant conversation or 1200 baud modem was frowned upon.
Yeah, my mate has been complaining about this, but was too lazy to dig through the settings on his phone. Concerned, I started writing him at 03:00 AM every single night (using pre-scheduled messages) which finally forced him to configure DnD after a week or so. No problems since. You should probably do the same.
Another good read on this topic is "Saving the Daylight" aka "Sieze the Daylight" by David Prerau http://www.savingthedaylight.com/ which describes at length the confusion and arguments in the USA when some organizations had different summer and winter timetables and others did not.
The argument is utter nonsense, so much so that I've often wondered if it was even intended to be plausible and not a (failed) joke. Neither part of it works.
Take the argument that it is currently easy to tell whether or not it's a good time to call someone on the other side of the world. Currently, supposedly, all you have to do is look up what time it is there. This is, frankly, bullshit.
I call someone with roughly a 12 hour difference from me every two weeks. If you haven't pre-cleared a time to call, then you do need to know whether it's daytime there. Even if you assume the best case scenario for the argument: where you need to call someone now if possible, and want to know whether that's okay, time zones are absurdly enough not better than the no-time-zone case. I fail to see how at all how asking Google "what time is it in Melbourne" is any better than "is the sun up in Melbourne". Moreover, both of them run the same risk: your uncle likes to sleep in on Saturdays, is busy, has an unusual schedule, etc.
So the correct question to ask Google would be "is it daytime in Melbourne?" Furthermore, if we abolished time zones, a fairly standard nomenclature for talking about "daytime" in a localized way would surely develop. Asking Google a question like "what time is it in Melbourne" would respond with e.g. "it's 2 hours after sunset". Why assume Google would respond with useless information?
But more importantly this puts aside the fact that very few people actually interact this way with people on the other side of the world, or even most of us with friends and family who live on the other side of town! If you're calling someone you don't see often for a nice long chat, you don't know what their schedule is like! Instead you pre-clear a time to call with them, through some asynchronous method like text or email.
In this case the no-time-zone situation really shines, and that's why the other half of the argument doesn't work. Your uncle writes you back: "yeah, call me at 4!" and you instantly know what that means.
When I talk to my friend on the other side of the world, it's hell currently. "Wait do you mean your time or mine?" Usually he means his, so I have to go to a website, figure out the hour difference between his time zone and mine, and figure out what that time is in my time zone. If that doesn't work for me, I have to suggest an alternative, and he has to wonder if that's in his time zone or not. It's a mess! The worst part is that if you're writing each other asynchronously it could take you days to figure out what a good time to talk would be!
You can't even count on getting days right, currently! The other day he messaged me: "can't wait to talk on Friday!" And I had to think, "Friday? I thought it was Thursday. Wait, he probably means my Thursday and his Friday. I guess it is Friday for him. Maybe I still need to check..." This is absurd! Without time zones, there would be universal agreement about what day it is.
> Without time zones, there would be universal agreement about what day it is
Sadly, it's not so simple.
Let's assume we just globally adopt UTC. Let's suppose GlobalFriday starts at midnight UTC, and runs through to the following midnight.
For a person in Hawaii, midnight UTC happens around the middle of the day - early afternoon. So, Hawaiians who woke up around 18:00 UTC on a GlobalThursday greeted GlobalFriday shortly after lunch. They go to bed on GlobalFriday evening, and wake up again on... GlobalFriday morning. GlobalSaturday will be rolling around shortly after lunch.
The interesting question then is, do Hawaiians go to work on GlobalFriday mornings?
Let's assume they decide to. For them, Friday-Saturdays are a workday in Hawaii, but Saturday-Sundays and Sunday-Mondays aren't (this is how Hawaii's work week runs today - they end their week on what they call Friday evening around 04:00UTC on a GlobalSaturday, and don't show up to work until 19:00UTC on GlobalMonday).
What about Australia, though? If they keep their current work week, they finish up around 05:00UTC on a GlobalFriday for the weekend - When they get up on a GlobalFriday morning at 19:00UTC (they today call that 'Saturday') they don't head to work at all.
So Friday-Saturday is a workday in Hawaii, but not in Australia. If you ask someone to schedule a meeting Saturday afternoon, will they think that's fine, or think you're crazy? Depends if they're Hawaiian or Australian.
You might think 'we can get Hawaii and Australia to agree on working the same days'
Obviously, they could, but that pesky international dateline winds up needing to be somewhere.
Fundamentally, the model we have now where New Zealanders are the first to get up on Monday morning and the first to pack up on Friday evening - with the rest of the world following the same weekday schedule on a time delay behind them - is a reasonable compromise not just around having clocks make sense locally, but also around us being able to share the same calendar globally.
> So Friday-Saturday is a workday in Hawaii, but not in Australia. If you ask someone to schedule a meeting Saturday afternoon, will they think that's fine, or think you're crazy? Depends if they're Hawaiian or Australian.
This is correct, but it doesn't show that there isn't disagreement about what day it is. It shows there's a (potential) disagreement about whether today is a workday.
Moreover, you're just re-describing a problem we already have now. If your business, based in Hawaii, wants to plan a meeting for Friday, and someone from New Zealand is supposed to be on the call, you're going to be disappointed to learn that they don't plan on going to work on what for them is a Saturday.
So this is in no way a problem solved by time zones, to the extent that it's even a problem. At least if you're in agreement about what date it is, the people in New Zealand can get back to you with a straightforward description of the problem: "sorry, we quit for the week at 5 on Friday, you'll have to schedule it earlier or bump it to next week".
Well, for a start, they can't say 'we quit for the week at 5 on a Friday' in your global timezone scheme - they have to say 'at 04:00 on a Friday'.
And it's not that it's a Saturday for them when they wake up in their local morning, later on global Friday - that's a day that starts out Friday and turns Saturday halfway through.
Meanwhile in India, Saturday starts first thing in the morning. Europeans get to generally be in bed when the day ticks over, so it stays Saturday all day for them. But Americans have to put up with the day changing in the evening - Saturday started at dinnertime last night, and it's still Saturday when they woke up.
So maybe you solve that by keeping local day names consistent - in the Eastern hemisphere you keep the name of the day that you wake up on, while in the Western hemisphere, convention is the day name you use is whichever day starts before you go to bed.
Congratulations, now you have an informal unspecified timezone that tells you region by region whether or not people there think it's Monday yet. Eventually, someone probably would formalize that, in some sort of localization file keeping track of the offsets when different places consider 'day turnover'. That file would look a lot like a timezone file.
And this is all before you start trying to associate dates with time periods. If you get rid of timezones and assume that the only 24-hour periods worthy of naming are ones that run from 00:00 - 23:59 UTC, you've condemned most of the world to not being able to use dates to unambiguously identify a given sunup-sundown period.
You'd have to use 'day ending October 19' or something to refer to the daylight period, in your location, that ends during the global 24 hour period called 'October 19'.
Sorry - it's just a real bugbear of mine whenever software devs try to wish away timezones that they ignore the importance of 'local midnight' in defining the boundaries between local calendar days. You have to propose a solution for that too if you're going to seriously suggest getting rid of local time.
> Well, for a start, they can't say 'we quit for the week at 5 on a Friday' in your global timezone scheme - they have to say 'at 04:00 on a Friday'.
Just for clarification, when I said "5 on a Friday", I wasn't making the error of thinking that New Zealanders could say that they leave work at 5 p.m. on Friday, I was (perhaps naively) hoping that along with getting rid of time zones, we would also be moving to 24 hour time, so "5 on Friday" means "5 A.M. UTC" in our current time spec.
> If you get rid of timezones and assume that the only 24-hour periods worthy of naming are ones that run from 00:00 - 23:59 UTC, you've condemned most of the world to not being able to use dates to unambiguously identify a given sunup-sundown period.
That's correct. To my mind this is the only downside of getting rid of timezones. As the OP of this subthread said, I'm quite happy to end up with the worst possible 24-hour-period to daylight mapping out of all of them in exchange for getting rid of timezones. I simply think the upsides to the proposal are so extreme as to completely outweigh this one downside, even for a person "stuck" with the worst outcome.
In response to your other points, my view is that we really should bite the bullet and always use UTC for everything (or whatever, it doesn't really matter; if making Beijing our universal time is the only way to get China on board, I say we do it). In other words, we do not compromise to keep local day names consistent. We always and only use "Sunday" to refer to 0-24 hrs UTC. My view is that people would adapt to this rather quickly, much as they would adapt to our switching to the metric system, despite the enormous number of complaints you hear about that. (My understanding is that those in the US military already do this as "Zulu" time, which makes communication much easier.)
My only point vis-à-vis cross-continent business hours is that this strict UTC adoption proposal does not make anything more difficult than it already is, and in some cases may make things easier. Right now, you have to think about what time and what day it is for someone on another continent. In my imagined future, you have to worry about whether the person is normally working right now. It's effectively the same problem, but communicating about the problem has suddenly become easier, because you share a language in which to discuss your available hours.
> Take the argument that it is currently easy to tell whether or not it's a good time to call someone on the other side of the world. Currently, supposedly, all you have to do is look up what time it is there. This is, frankly, bullshit.
It's actually much easier than that. Just call them, and if they're asleep their phone will be on silent.
But honestly, who do you know who lives on the other side of the world, and you're close enough with them that you would give them an unscheduled call, but you're not close enough with them to know what times are good for them to receive phone calls, and you're worried that they would be upset by a phone call at a bad time?
You're right, the case as given in the essay is a pretty massive stretch from anything reasonable. What I was hoping to show was that even if you take it as straightforwardly as possible, it fails on its own terms. A universal time used by everyone would make it easier to communicate even in this case.
If you're saying we should have a global standard reference time, sure I agree but we already do: Zulu/UTC. e.g. the US military uses it despite it not being local to anywhere in the US.
But you don't just want to throw away local time. Local time is important shared nomenclature for "point in a day". If you throw away local time and just say "I had a visitor at 0300 yesterday" you're leaving it up to the listener to both figure out where you live and do the math for whether you had an unexpected night visit or somebody interrupted your dinner.
On the contrary, if I say "I remember it was 5:30pm when I saw X" you can immediately picture the setting. With a world time, you'll need to know where the location is, too.
Besides, as the parent said, we already have a world time. Use UTC.
You'd save a bit in some cases but now you'd have the problem of trying to schedule meetings because "8 am" is no longer tied to an area, so you have to now take location into account, which is what timezones already do.
8am is already not tied to an area. If you say "let's meet at 8am" in an email to a bunch of people and don't know where they are there is a good chance that most or maybe even all of them will show up at the wrong time.
I always just basically ignore TZs and always use UTC when communicating with my international team. Only using a single timezone for everything simplifies things a lot.
How do you handle DST? That's the only wrinkle I can see, recurring meetings changing time based on the season. With location-specific meetings, we've been lucky so far and all countries involved switched to DST at around the same time.
That's exactly the issue -- you want your local meeting at a particular local time, and if you schedule it in UTC, the meeting shifts by an hour twice a year.
this isn't a solvable problem with a sufficiently dispersed group. not even all US states observe DST, let alone all the countries in the world. you can't set a recurring meeting that will always be at the same local time for everyone.
Which is fine when you know the other people are in another zone, except they then have to do the conversion in their heads. If you speak like most people do when not thinking about time zones you just say a time. If time is the same for everybody then there is never any confusion. The computers are all doing it in UTC under the covers. The conversion is just because we have arbitrary layers on top of that.
PDT meaning? The reason for using Continent/City is that it's unambiguous and it's easy to find out what the time is in a city -worst case you can ask someone who lives there.
But PDT is unambiguous. It is used for nothing except Pacific Daylight Time. That was standardized a long time before the Olsen database which added Continent/City as a convenience.
Luckily, I'm in the middle of a work-avoidance session, and I found some delicious trivia[0].
'''
Unlike most of the United States, Arizona does not observe daylight saving time (DST), with the exception of the Navajo Nation, which does observe DST. The Hopi Reservation, which is not part of the Navajo Nation but is geographically surrounded by it, also does not observe DST. For this reason, driving the length of Arizona State Route 264 east from Tuba City while DST is in place involves six time zone changes in less than 100 miles (160 km).
'''
That’s a problem I already have, because I can never remember what time zone people or places are in. On the other hand, with a single time zone, there is never any ambiguity about what time someone/something is referring to (Eastern or Western? DST or non-DST? Etc)
You still have to remember where people live. Just because it's 9am everywhere doesn't mean people on he opposite side of the globe will work through the night.
That's already a solved case: communicate using UTC times when dealing with people in other timezones. It then becomes their responsibility to know their time relative to UTC. There are even sites that you can set a clock for a specific UTC time and when people visit the URL it will use their local time so they don't even need to deal with converting to/from UTC at all - technology does it for them.
I always wonder how fast the world forgets when this comes up..
TLDR; Swatch make a decimal based 'world time' and watches/programs to track it ('beat time'). Put a huge 'beat time' clock on their HQ. It was supposed to cure all the internet scheduling woes...and then it died.
The problem with working (or communicating) with people in other timezones is not simply time conversion. The problem is that they are at a different phase in their day. So even if you flip everyone to UTC, you'd still have to figure out and understand what the others might be doing over there. The only issue is that now it's harder. Because now it's not enough to know the time difference, you also have to understand (or somehow convert) to their local phase. E.g. if you are just after lunch in the US on the East coast (what used to be 1PM in EST for you but now 5PM UTC for everyone) then you'll now that it's 5PM for your Indian and European colleagues but will have no idea whether they might still be at the office. So you'll have to know when their day starts and ends in UTC. And keep that in your mind.
The current system is a lot simpler. You have a rough idea when people sleep and work: it's the same time in their time zone as it is for you in yours. (Unless you are as shifted as e.g. me :) . But even then, the 'normal' people follow a normal schedule.) You just have to convert it to yours. Not that hard.
Seems like some people think "The whole world should just change to accomodate me!". I guess they should imagine if the world standardize it but based on e.g. Beijing time, if they'd like to start their work days at what used to be 9PM local, have lunch at what used to be 2AM local, and finish his day at what used to be 6AM local.
Well, I think the idea above wasn't that you shift your schedule (relative to the Sun) but that you keep it and get used to that your work day starts at what used to be 9AM but now the clock says it's 9PM. And it would be 9PM at the same time in Beijing, and in London but you'd have to know that 9PM means evening in Beijing and early afternoon in London. Which is a lot harder and a lot more to remember than simply knowing the TZ difference to these two cities. (Because you'd have to remember when the morning starts, when it ends, when afternoon starts, ends, etc. for each timezone.)
As a more problem-specific solution, I'm an advocate for any team/company/etc. with employees in more than one timezone standardizing on UTC for everything. We do it with servers and it works pretty well.
It seems the status quo for remote companies is to standardize on whatever timezone the top-most boss is in. Doesn't seem optimal.
How does using UTC help? You still have to remember the time-offset between EU and USA and India to make sure your meeting is during somebody else's dinnertime (or worse).
It doesn't help with that but neither do timezones. When I communicate to people internationally I'll need to know their daytime hours in terms of my timezone anyways, so why not know them in terms of UTC? Then everyone can start on the same page.
I'd be happy if we said "There are 24 time zones and no daylight savings or half hour zones or whatever, they are distributed evenly from GMT starting point".
And then I'd love a watch that was a digital sundial. I just want to know where the sun is in the sky even when it's not in immediate view. And Outlook synced to my personal time. I'd also have the "default" time zone available for when I'm communicating with others.
I'm with you. Abolish timezones and make times based on sunrise/sunset again. E.g. the workday shouldn't be "8am to 5pm" but "one hour after sunrise till sunset". This makes a lot more sense for our health and biology
That doesn't make sense for anyone far from the equator. Here on the shortest day the sun rises at 9 and sets at 4 (7 hours daylight). On the longest it rises at 5 and sets at 10 (17 hours).
The different between the longest and shortest day's amount of daylight is a whole workday.
There is a trend to move to permanent daylight savings time in some places. I understand wanting to avoid the twice annual time changes but why "permanent daylight savings time" - why not "permanent time"
Our society has stabilized on a business schedule and sleep pattern that is asymmetrical about noon; most people stay up after 6pm and wake up after 6AM, regardless of when the sun rises and sets in their locale. If you live in the perfectly calibrated point for your time zone (such that the sun is directly at its apex exactly at noon, with the caveat that you aren't on the equator) you will experience the sun rising before 6AM for half the year, and setting before 6PM for the other half, leaving you with wasted daylight in the summer and lots of darkness during waking hours in the winter. Since a larger portion of our waking (and non-working) hours are after 6PM, the thinking goes that it is beneficial for more of the year to bias your daylight to the evening by an hour than to actually be perfectly calibrated to solar noon.
I would wager it's a combination of psychological factors: most people in the northern hemisphere prefer summer to winter, and falling back an hour in the fall in combination with the shorter days in general means that most people waking up hours before sunrise, which is unpleasant.
(Shorter winter hours are universally unpleasant, so it's not obvious there's a good answer regardless.)
In Eastern Canada (Montreal for instance) when we go back to normal time the sun will set at around 4:30pm which is depressing to say the least. I think most people would rather have an extra hour during the evening than in the morning.
Is UTC not a time zone? Apparently UTC is based on TAI.
International Atomic Time (TAI, from the French name temps atomique international[1]) is a high-precision atomic coordinate time standard based on the notional passage of proper time on Earth's geoid.[2] It is a continuous scale of time, without leap seconds. It is the principal realisation of Terrestrial Time (with a fixed offset of epoch). It is also the basis for Coordinated Universal Time (UTC), which is used for civil timekeeping all over the Earth's surface. UTC deviates from TAI by a number of whole seconds. As of 1 January 2017, when another leap second was put into effect,[3] UTC is currently exactly 37 seconds behind TAI. The 37 seconds result from the initial difference of 10 seconds at the start of 1972, plus 27 leap seconds in UTC since 1972.
I believe the author is referring to leap seconds? International Atomic Agency is I think jumbling up the International Atomic Energy Agency and International Atomic Time. The agency responsible for leap seconds is the International Earth Rotation and Reference Systems Service (IERS); the IAEA is not involved in timekeeping standards as far as I know.