Hacker News new | ask | show | jobs
by anileated 134 days ago
I don't think global time would be a problem like many people suggest. If you're in US and talk to somebody in Australia, you will quickly develop an intuition that time @X is night (or whatever it happens to be) over there, just like our other intuitions about how many things (weather, season, how long are sunsets, etc.) are different in different places.

Timezones are failing at all of their jobs. Getting time to correspond to sun position? It can be 7pm here and 7pm there but here it will be fully dark and there it will be still mid-evening. Knowing working hours of shops and government? Everything is all over the place. Everything is fluid and changes with seasons.

Plus, there is this unfair specialness that some countries are at UTC and others have offsets. With global time, everybody gets @0, just for different places it will be at a different sun position. (As long as we find a political way to pick something neutral, instead of saying "that's when the sun is highest in London".)

Finally, we don't have per-latitude calendar and things are working fine for us. It's February here and February in Argentina, and yet life doesn't stop even though it corresponds to winter here but to summer there.

3 comments

It's worth noting that technically London uses GMT for 5 months and BST for 7 months.

The GMT offset is zero, but it's important to note the difference especially when configuring servers to avoid nasty daylight savings surprises kicking in at at end of March.

There has been talk of moving to a +1 offset all year round for lighter evenings in winter, albeit at the cost of some very dark morning, but given we couldn't even manage Metrication without people still complaining 20 years later, I can't see it ever happening.

I think you mean complaining about metrication 50 years later :-)

The counterpoint is that without the metric system how could we make snarky comments on US-based woodworking videos?

I was specifically thinking of the "Metric Martyrs" who were jailed over refusing to display weights and measures in metric.

The law requiring metric didn't actually come into force until 2000, these cases were early 2000s. Note that the law to this day still allows for imperial measurements to also be displayed, but they wanted to display in solely imperial.

https://en.wikipedia.org/wiki/Metric_Martyrs

The situation another 20 years later is rosier, even the boomers have spent most their adulthood with metric, and they're dying off now.

> There has been talk of moving to a +1 offset all year round for lighter evenings in winter, albeit at the cost of some very dark morning

Why not just offset the office and opening etc hours by +1?

Because society and culture doesn't work like that.

You can't will a culture of closing up at 4pm during GMT and 5pm during BST. That's just even more confusing.

The talk was +1 offset in clocks all year around, in effect dropping DST and changing the timezone.

Also a lot of places and services have different hours during different seasons.

If you're going through the hassle of dropping DST, why not settle on BST as the permanent timezone if that's what the preference is for hours of daylight?

Asking an entire culture to change from 09:00-17:30 to 08:00-16:30 seems awkward and doomed to failure in comparison to simply landing on BST instead.

the obvious solution is to move it by .5 the whole year round.
Australian here!

I constantly forget which way the half hour difference is between Adelaide and Melbourne / Sydney!

Then I have regular contact with offices in London and LA. For some of the year it’s not too bad, and then our clocks switch the opposite way and it gets less convenient! Which way is which I can never remember.

Queensland doesn’t bother changing their clocks at all.

Writing software that deals with Timezones isn’t too bad these days, but supporting it is as it constantly confuses users I find!

You have some fun ones. On the other side of the spectrum is PRC, where at the same hour of day it can be complete darkness on one side and almost technically noon on the other. It's super arbitrary with little rhyme or reason.
I used to think this, but mirroring the sun position makes a lot of sense. If I wanted to meet w/ someone in Australia, I would still need to know extra information (what their equivalent 9-5 working hours are).
You would need to know that person's working hours, so I don't see how you are avoiding something.

Sure, if you talk to someone there for the first time, you would need to learn what time is generally day/night. However, you will know that 2-3 times in. Just like you would automatically know that now it's summer in Oz, or 3 hour short days near Arctic circle, if you talk to anyone from there even very occasionally.

Case in point, we have global calendar with no problems.

My point is either way you need to memorize some info in the first couple of interactions and it really doesn't make sense to go through all of this change to just memorize a different thing.

If you really need to coordinate something across many timezones, you currently have the option to use UTC to specify the time.

Following the sun also gives a lot of context. (i.e. if my flight to China lands at 9p local time, I immediately know that it's going to be night, but if my flight lands at 1PM UTC, I really have no context as to what time of day I'll be landing)

> My point is either way you need to memorize some info in the first couple of interactions and it really doesn't make sense to go through all of this change to just memorize a different thing.

It's at least to make time management in systems much less error-prone and complex, among other things.

> if my flight to China lands at 9p local time, I immediately know that it's going to be night

What does that imply? If you mean "it's going to be dark", not really (you need to have more context to assume it's going to be dark at 9pm, there are places where in summer it's still very much light at 10pm). If you mean something like "buses are going to be running and McDonalds will be open", not really (you'll need to check the schedules anyway).

> It's at least to make time management in systems much less error-prone and complex, among other things.

I'm sure people deal w/ more complex issues, but 90% of it is covered by storing everything as UTC and doing the conversion on the frontend.

> What does that imply? If you mean "it's going to be dark", not really (you need to have more context to assume it's going to be dark at 9pm, there are places where in summer it's still very much light at 10pm). If you mean "buses are going to be running and McDonalds will be open", not really (you'll need to check the schedules anyway).

It implies a lot, including that less things are likely to be open, it's likely to be dark, and that I'll probably want to get to bed within a couple of hours to wake up for whatever I'm doing the next day at a reasonable time in the morning (i.e. how to adjust to the daylight cycle there).

Things you will have in context when traveling: "it's going to be cold", "it's likely to rain", "it's going to be government conference so there will be extra delays with transport", "it's going to be %holiday% so everything's going to be closed all week", etc.

You're so used to it you don't even question that, and if you add to that "@x is when sunset usually happens"... somehow I think the world will not come crashing down.