Swatch Internet Time (1998)
en.wikipedia.org
en.wikipedia.org
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.
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?
Choose one and stick to it :-) Customary xkcd: https://xkcd.com/927/
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.
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 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...
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).
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.
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.
With a little cut-and-paste of some code from Swatch's website you could have a GIF 'clock' on your site that showed the 'internet time' to your visitors. Utterly pointless, but harmless fun.
Not normally an issue for average users, but yet another disadvantage of a non-absolute time scale. And a reason why people keep trying to reinvent measures of time.
GPS tracks TAI, because TAI is an Atomic Time, it doesn't care about how the Earth moves in space. Some of the metadata transmitted alongside the GPS signal tells a device how to turn GPS time into UTC at the current moment in case you want to display that, but it's orthogonal to the main purpose of GPS which is to figure out where you are, for which you want a nice steady time system like TAI, not a civil system like UTC.
The way UTC works is, moment by moment it goes at the same speed as TAI, but every six months it might jump back or forward one second, to try to keep it roughly lined up with UT1. This is a compromise to give TAI's simplicity and reliability (atomic clocks are easy) but without gradually shifting away from UT1 over decades.
Why? Well, UT1 reflects the thing humans think "days" are about, the uneven wobbly spin of Earth, the big round thing we're almost all stuck to. If the Earth spins a little more slowly or quickly than expected, that's reflected in UT1 but doesn't affect TAI at all.
So in practice, you have to rely on what national labs provide. They provide time that is close to UTC but is not actually UTC, in the case of GPS they use the approximation of UTC by the US Naval Laboratories.
Now because UTC is the official civil time, and it is easy enough to compute TAI from UTC, what such labs provide is UTC.
Then internally, GPS translates that to GPS time. Which differs from TAI by 19 seconds.
(Tongue in cheek but I get the point: those who need a universal time can already use it)
I still struggle figuring out times globally, without good reason. Local time could still be the regular 24h, but for business meetings, etc. something like Swatch Internet Time would be great.
* https://metropolitan.fi/entry/finland-seeks-to-drop-daylight...
> for business meetings, etc. something like Swatch Internet Time would be great
Let's discuss this on 2018-06-07 at 04:30, UTC.
I thought Google would be the easiest source for a conversion, but for me a search for "04:30 UTC" gives a banner at the top, "17.30 Tuesday, in Denmark": https://www.google.dk/search?q=04%3A30+UTC
So maybe one problem it solves, is the American assumption that everyone uses the 12-hour clock.
I'm an American, and I was not aware of the "American assumption that everyone uses the 12-hour clock." Please elaborate further.
It's definitely in keeping with how we mix meters/feet and pints/litres.
Uh, yeah, I'm well aware of that, as are most Americans I know. That's why I asked about "the American assumption that everyone uses the 12-hour clock". That must be a myth that non-Americans believe in.
My computer is configured correctly, but it's rather common for an application (especially a phone app) or website to ignore those settings, or to think it knows better.
04:30 UTC means 04:30 UTC, or 05:30 in Denmark. Not 17:30!
The same can happen if I type something like "04:30 Catch flight" into an appointment in my Google Calendar. It is converted into a new appointment "16:30 Catch flight".
It's not just Google. "Your Office 365 subscription will automatically renew on 1/19/2018." and the admin interface is a mix of date and time formats.
C'mon, stop. So edgy.
It isn't quite so extreme as that edgy metric system trendiness all the kool kids seem to be in to these days, but, uh, there is a world out there.
Perhaps the writing is silly, but there's nothing silly about the point the point that of course people will maintain the solar day for daily life, and abolishing timezones will basically break time for most people (especially those whose "midnight" (and so the changing of the date and name of day) will land during the solar day).
Consider: in a world with timezones, all you need to know is what time’s in Melbourne right now, and what time Steve’s typically awake these days. In a world without timezones, all you need to know is what time Steve’s typically awake these days.
What about 0000 hitting in the middle of the day? Well, a bar I recently went to is open “Thu–Sat 8pm to 4am, Sun 8pm to 2am, Mon–Wed off”. In a world without timezones I don’t think anyone would be confused by a sign like “Sun–Fri 2300 to 0500” at a post office or barber shop.
We have tools to deal with timezones, so that complexity is pretty much hidden these days. That said, I can’t help but notice every now and then how leaky the abstraction is. Humans are not machines—more and more people work independently or on flexible office hours, many businesses are routinely open different times depending on the season even if the country uses DST, and so on.
-I was once told (and found it too amusing to verify the truth of it!) that as GMT took hold as the go-to global time reference, the French grudgingly complied, but referred to it as 'Paris time minus seven minutes and twenty-six seconds' or something to that effect.
The applicability of timestamp conventions for setting business meetings is largely dependent on how easily one can look up the same moment across multiple IANA timezones [1]. For example, looking up how typical local working hours cascade between different timezones [2]. If multi-converters like this became mainstream, Swatch Internet Time may very well have been a hit. But it wasn't, and such a tool, even for UTC, remains hard to find.
[1] https://www.iana.org/time-zones [2] https://www.timeanddate.com/worldclock/meetingtime.html?iso=...
Inter-continental multiplayer or livestreaming is made easier if you don't have to convert timezones.
(It may be pointless to reply to a comment that's already several kiloseconds old on here, I know, but hopefully at least a few dekapersons will read my reply and enjoy it.)