Also, I don't think the comparison with the metric system is apt. It took a pretty intuitive system and replaced it with another slightly less intuitive system, but which is vastly easier to use for a large number of tasks that a large number of people need to do frequently (specifically, arithmetic on measurements). Timezone abolishers will bring about benefits that only a very small number of people will enjoy, while causing very significant confusion to practically everybody.
A foot consists of 4 palms or 12 thumbs (inches). A fathom is distance of arms outstretched (6') and so it goes on. Many fractions and multiples can easily be achieved without resorting to scale or rule.
You can trace all the way back to Egyptian/Roman times though many had their standard size fiddled with over the years. The German foot was a bit longer, a French pound (livre) a little heavier etc.
Of course if you're mucking about in a globalised world with software, or engines, satellites and suchlike SI units are a much better bet.
Once we get to miles, I don't think that those have any advantage over kilometres (of course, we could have a hybrid system with kiloyards, to get the advantages of both).
And what about fahrenheit and pounds?
After 50 years of only metric in UK schools? We've mostly switched most of the time, and I'm amazed we're not there yet! You still often hear people referring to temperatures by Fahrenheit decade (50s, 80s etc) though I can't remember the last time I saw a forecast ever use F. Everyone still seems to think of their height or weight in imperial. Beer comes in pints. There's a few other strange holdouts.
Choose one and stick to it :-) Customary xkcd: https://xkcd.com/927/
I wonder how much money each year is lost to software bugs and development costs involving time zones and DST.
The general arch of tooling is that the tools evolve to be more useful in the world, not that we change the world to suit our tools better.
In general yes, but for the entirety of our field, dealing with time zones has been painful, and the way time zones are setup, it will continue to be painful into perpetuity.
Random governments changing time zones, and DST dates, whenever they want, makes for a headache. Dealing with DST and time zones, a major headache. There is no eloquent way to do it, meaning that all code that deals with time across more than one geographic area, ends up having bugs.
> I wonder how much money would be lost to putting together the system that will have to replace time zones because people will still have the problems that time zones fix
24 hour time, print signs out accordingly.
Instead of businesses typically being open for lunch from 1100 to 1300 local time, they'll be open for whatever time people feel like lunch.
And Daylight Savings needs to die, it has already been shown that it is actively detrimental to people's health[0], and places of business that care about daylight hours end up adjusting their operating hours on top of the DST change! Get rid of DST, and businesses will have to shift their "Open until" sign by 2 hours instead of 1.
Properly doing time zones is insane. To do it 100% accurately and automatically in today's mobile world is even harder. A phone's time zone can shift during the middle of app usage, and DST can shift if the user drives down the road a bit!
Every platform has to implement a way of getting updated time zone definition files, and apps running have to then be aware that the definitions of time zones has just changed. Most often not a problem, but it a hell of an edge case.
Indeed everything about handling time is just a bunch of edge cases. The base case works well enough: get time in UTC, translate to local time. Things not in the base case suck.
For example, appointments on a calendar, the UTC time of appointments moves backwards by an hour when DST hits to keep appointments at the same local time.
What do you do when participates are in multiple time zones and some have DST and some don't? How do you get everyone to meet at the same time?
What about events that are absolute in time, that ignore DST? How do you know not to move them? (Checkboxes? lovely!)
What format do you store appointments in? Local time? Makes it easy to handle the DST shifts, but it is otherwise bad mojo. UTC is the go to, and then store a field of what time zone the appointment was originally created in, check what its DST setting is on any given day, do the math, and place on the user's local calendar accordingly.
That is one strategy, there are others. They all have trade offs.
[0]https://www.cnn.com/2016/03/11/health/daylight-saving-time-h...
At the expense of being vastly more difficult for a large number of tasks that a large number of people need to do frequently (specifically, manipulation of physical quantities).
What do I mean? It's very, very easy to take a pound of some substance and reduce down to ounces with a balance: halve, halve, halve & halve again. It's very, very easy to take a gallon of some liquid and reduce it to gills: halve to get 2 pottles, halve each again to get 4 quarts, halve each again to get 8 pints; halve each again to get 16 cups; halve each again to get 32 gills. It's easy to cut a yard into feet (thirds) or a foot into inches (thirds, halves, halves).
But it's very difficult to manipulate physical quantities in the French Revolutionary system: if you have a kilogram of some substance, turning it into decigrams is … a right royal pain, because dividing a weight into tenths with a balance is a chore; you need a set of pre-measured weights to do it. Ditto with a litre; ditto with a metre.
If the French had really wanted to make a difference, they'd have chosen to introduce a different base for arithmetic …
(I certainly agree that it's nice that the whole world has settled on one standard; I just wish that it were a better standard. Much the same as with computing & x86/C/Unix.)
That's performing arithmetic (and you're of course correct: in base 10, multiplying by 10,000 is really easy — just slide the decimal point right), not manipulating a physical quantity. Take a gram of sand, and try to cut it into 10 decigram-weight quantities using a balance without a pre-existing decigram weight. You're going to have a hell of a time: there's no good way to divide a physical quantity of stuff (whether a volume, a length or a weight) into tenths. It's much easier to divide things into halves and (less easy) thirds.
Thanks for commenting, though. I wonder if others misread similarly (and I've added one word to clarify). I can't imagine anyone seriously believes that it's easier to divide quantities of physical substances into fives or tens than into halves.
(as an aside, the HN rate limiter has been insane this week: I posted one article and three comments, and I've not been permitted to post for over an hour now)
Granted, if we look at the tiny details, the exact measurements of each size are not what one would call intuitive, round numbers, but it's much easier and reliable to use than the US, non-decimal based standard.
I think it's mostly an economic problem, for the majority of people it's too much trouble for very little real gain. For engineering, on the other hand, it's almost mandatory.
I really just wish we could ditch DST. DST is horrible because the rules vary from year to year, not just from place to place.
Obviously, this means that you can’t rely on timezones to determine business times.
And then there’s cultural differences, in some countries people will eat dinner between 21:00 and 22:00, in others around 18:00 – this has obvious consequences for business dinners.
The problems you describe are due to cultural mismatches and these can't really be solved by any other system.
Of course you can, you just need to know in which timezone they are (except for the China case, maybe).
Other than that I find our time system very straight forward: about 9 billion cesium phase transitions make a second, sixty seconds make a minute, sixty minutes make an hour, etc. Every six months check in with IERS whether a leap second is scheduled (or find it yourself by calculating mean solar timbre and checking its deviation from your atomic clock). If a leap second is due, the minute 23:59 has 59 or 61 seconds (displayed as 23:59:60). To get local time look up the local UTC offset and add it.
If you calculate in local time, time may repeat one hour due to DST, so just stay in UTC and convert for display. We have a homemade problem because computers pretend that every minute has 60 seconds, but that's not the fault of the time system.
Meet you at 20? I might get off work late, so better make it 21, and I have to be in bed no later than 40, so I can be up by 72.
Some time systems roll over at midnight (24-hour base-60 clock) some roll over at noon (Julian day) and some roll over at both (12-hour base-60 clock). You shouldn't assume anything about a timekeeping system that has never actually been used.
Besides that, if such a clock had time zones, they certainly wouldn't be aligned to hours. If it had no time zones, you would have to know where on Earth the hypothetical conversation took place, and what the typical sleep schedule is there.
Though I'm sure people like me would be irritated by that leftover 400 second bit every day, where you don't get a whole kilosecond before rollover, and it may be that everyone arranges things by consensus such that it usually happens while people are sleeping, wherever they may be. So you might be right. Zero could correspond roughly to around 3 AM by the old clock, just like with the DST transitions.
The reason I think it doesn't catch on is that what we have really isn't too bad. If I'm thinking locally, everything works perfectly. If I'm trying to schedule a meeting with my colleagues in Singapore, I just remember a single number, 14 and apply it to my time. I know that right this minute, it's 21:40 in Singapore, and I know that the sun is down, everyone is home and preparing to go to bed. With UTC, I have to remember that the sun rises at 23:00UTC, do a little math, figure people show up in the office around three hours after the sunrise, etc. Toss in offices in London, Shanghai, Cape Town, Melbourne, etc. and it gets confusing.
Modulo 24 math is simple enough that anyone can do it, and looking up the offset for a city is much easier than finding out a "normal" person's schedule in that city.
Yes of course it gets a little silly with edge cases around DST and strange places (good trivia question: with what city does the South Pole share its time zone? A: Auckland, NZ, where the logistics are handled or anywhere in NZ really), but it works 99% of the time.
Could we make it work if we just decided to? Of course! Implementing the metric system was much harder, and we did that (well, most of us did, of course) because there were huge benefits to being on the same measure. Are there equally huge benefits to being on the same time zone? I doubt it.