The tight-knit time zone data maintenance community
onezero.medium.com
onezero.medium.com
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.
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).
https://github.com/eggert/tz/blob/43dbb43381487a253fdc4462c0... for Mauritius is representative
Although it seems like a few more events have passed since then.
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?
https://github.com/eggert/tz/blob/43dbb43381487a253fdc4462c0...
# 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.
Does anyone know where the author got this from?
Wikipedia suggests that it was done to facilitate telegraphs, which makes a lot more sense. https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Irelan...
"Inspired by a script written by Paul Eggert."
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.
Chesterton.org, on the other hand, had me going through not one but two select-all-the-boats captchas to even see the content.
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.
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.
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".
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.
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.
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?
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.
If I know where you are, then I already know what you meant by "yesterday". If I don't, then local time has no upside in that regard.
This is the internet. I don't make assumptions as to where people are located unless it is relevant to the topic
Besides, as the parent said, we already have a world time. Use UTC.
Daylight Saving Time (DST) is not used for UTC as it is a time standard for all time zones
PDT might be, but others aren't (e.g., ACT, ADT, AMT, and AST are all ambiguous, and that's just in the As)
''' 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). '''
Good thing time zones are there along side UTC+/- whatever to help you out with that
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 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.
It seems the status quo for remote companies is to standardize on whatever timezone the top-most boss is in. Doesn't seem optimal.
We support multiple timezones. PST and PDT.
Not to mention that a lot of countries mandate that the civil time should follow the Sun.
First, go buy an Apple Watch...
https://www.macstories.net/linked/the-beauty-of-the-apple-wa...
(It is a pretty cool watch face, and I use it a lot in the Pacific Northwest winter with its early sunset.)
The different between the longest and shortest day's amount of daylight is a whole workday.
ok, but how is daylight time better? Just open and close stores at the times people are awake and active.
(Shorter winter hours are universally unpleasant, so it's not obvious there's a good answer regardless.)
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.