Hacker News Reader

Comment by mseebach | Hacker News Reader

It's a near-perfect instance of Chesterton's fence: https://www.chesterton.org/taking-a-fence-down/

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.

View on HN

What about customary measurements was more intuitive than metric?

More people have a foot to hand (ha!), than have a meter.

They tend to be easier to visualise stemming from so many having root in human scale. For instance an inch is the width of a thumb - it'll match scale on many common charts so easy approximation of distance. (one of many dubious claims of the origin of "rule of thumb")

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.

OK, I'll concede that on length measures between one inch and one fathom, customary measurements might have an intuition advantage (and indeed, I've been known to measure things with my own feet before converting to metres).

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?

Fahrenheit is "tighter" and has a better resolution in the "human" range -- ie. 0-100 degrees fahrenheit is roughly the range of temperatures that humans can exist in, and one degree celcius is a bit too coarse for human comfort, thermostats generally give you at least half degrees celcius precision, but can get by with only whole degrees fahrenheit.

We can discuss all sorts of reasons why one system is better than the other one but the worst situation is to have more than one system to measure the same thing. Measuring longer distances by foot instead of meters makes the error bigger. Many small feet adds small amounts of errors on each foot. One meter is an average step so less errors that adds up.

Choose one and stick to it :-) Customary xkcd: https://xkcd.com/927/

Miles/KM and the rest? Don't think it matters at all, except cost to replace or move all those mile/yard road markings and signs. The UK ruled out a switch of roads once cost became apparent even as everything else has metricated and gained metric only legislation.

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.

> Timezone abolishers will bring about benefits that only a very small number of people will enjoy

I wonder how much money each year is lost to software bugs and development costs involving time zones and DST.

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 (and then how much money will be lost to bugs in that).

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.

> 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...

> vastly easier to use for a large number of tasks that a large number of people need to do frequently (specifically, arithmetic on measurements).

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.)

I'm a bit baffled by how you think turning kilograms into decigrams is 'a right royal pain', multiplying by 10000 seems pretty simple to me.

> I'm a bit baffled by how you think turning kilograms into decigrams is 'a right royal pain', multiplying by 10000 seems pretty simple to me.

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)

Dividing a gallon into tenths is easy. Pour it into a measuring cup until it's at 1/10th of a gallon. With sand by weight, pour it onto a balance until you get your desired weight. Easy peasey.

I'm not sure about physicality being the problem here, the ISO 216 standard, based on metric units (square meter), is used for dividing and multiplying the areas of physical things (paper) and seems to be doing rather well, each size being half of the previous one, I would say that's quite intuitive.

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.

Reply on news.ycombinator.com