Hacker News Reader

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.

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

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.

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.

I don't think the world would come crashing down, but what's the point if it's just another thing to memorize?

The total cost/effort of timestamp translation in systems is not as high as people make it out to be.

> just another thing to memorize

Not knowing what time it is for my Australian colleagues at all without checking my phone every single time is worse. Remembering N timezone offsets (remember DST and half-hour offsets, too) is worse. Doing UTC translation or adding "my time/your time" every time is worse.

If you talk mental overhead, current system is like 10x of that than global time.

We agreed to meet at "8pm their time" but unless I literally put it into my TZ-enabled calendar app every time the chance I mentally translate it to my TZ wrong is unacceptably high. With global time, meeting would be @123 and that's it. I can keep it in my head or write it down on paper, no confusion and full precision every time. I don't even need to know if it's day or night if it's a remote call with the other side of the Earth, maybe me or my colleague works late, who cares, but I know what time it is there at any moment.

> is not as high as people make it out to be.

It's not just timestamp translation and all the errors that come from that, it's all the rest of it, waste standardizing timezones and moving them around, having to convert time all the time, missed meetings, etc.