[GreenNight]

Timezones are not an ugly hack.

When you travel to a different timezones you just have to adjust your clock and, without asking, you know that shops open at 8~10am until 4~8pm with or without a midday stop for lunch (12~3). You have dinner at 18~22, and breakfast at 8~10. All the divergences depend on the country you are in but you can get good aproximations that work for 90% of them (breakfast 9, open shops 10, lunch 13, close 17, dinner 20).

But, if you go for an universal timezone, you've got to learn the different times for the different activities again and again and again. You change a one step correction (change time on your watch) to a constant struggle.

With universal timezone: You wake up when travelling, it's 17:30 and you don't remember the country unless you do the mental effort to wake up, it's time to get up or not? You start to calculate and... too late to decide, you are already woken and could not get back to sleep even if you wanted.

With different timezones: You wake up when travelling, it's 2:30 and you don't remember the country unless you do the mental effort to wake up, it's time to get up or not? No, time to sleep some more.

[jarin]

I ran into a big problem with timezones when I was in the Navy.

I was in charge of a big supply database server on an aircraft carrier, and every time we changed timezones I had to update the timezone on the server. Heading from East to West was no problem, but when we went from West to East I had to shut the server down for an hour when changing timezones, to prevent timestamps from overlapping.

Admittedly, this was partially due to bad programming, but it's just a small real-world example of problems caused by the existence of timezones.

[vacri]

It's wholly due to bad programming. Put the timestamps in epoch time - that never changes, then read them back in whatever your current timezone is. If you're in a situation like you were where timezones change frequently, you'll also need to record the timezone when the entry was made for reference.

Given that servers frequently changing timezones can be sorted out by a modicum of thought by programmers and is actually pretty rare in the grand scheme of things, I don't think it's too heavy a price to pay.

[azernik]

Best practice - whatever time zone the people are using, keep the internal time stamps on a single time zone (usually UTC). Then just convert the times from and to the local zone for input and display, respectively.

[masklinn]

> keep the internal time stamps on a single time zone (usually UTC)

Or UNIX time. While not monotonically increasing (it has issues with UTC leap seconds), it's pretty good.

[rmc]

Just store all the dates and times in UTC, then convert to local time

[mikeash]

With time zones, you have to know which time zone you're in and set your watch accordingly. With no time zones, you have to know what time local noon is and interpret your watch accordingly. The amount of information required, and the difficulty of using it, appears to be the same to me.

[Someone]

For the common case of infrequent changes in time zones (relative to the number of times one does a time lookup or talks about time), I think what we use now is less difficult to use. You only have to make the adjustment once, instead of every time you talk about times.

[mikeash]

It seems to me like the opposite is the case. I have to coordinate times across time zones way more often than I actually travel (for online meetings and such). If there was a single time zone, I'd never have to make adjustments for those, and only adjust things when traveling.

[jsharpe]

The problem there is that in a lot of cases you pretty much use timezones implicitly anyway. If you want to call someone in China from North America, for instance, if it's 3pm where you are, you might know that it's 3pm in China (in this hypothetical no-timezone world), but that still doesn't tell you if it's a reasonable time to call. You have to think, "Well, people in China usually work from time X to time Y, so their time X is my 9am, which means the offset is Z, which means 3pm in China is equivalent to my 3pm + Z, which means it is/isn't a good time to call."

You basically have to reinvent timezones every time you make any kind of calculation involving people in another timezone.

[mikeash]

Right, so you do the same calculations in those cases, but, when someone proposes meeting at 3PM, you don't have to do any conversions. Some upside, no downside, unless I've missed something.

[Someone]

OK. So you are traveling and your plane goes at 15:00 (with this hypothetical clock, I would drop the PM stuff). Do you have time for lunch beforehand? Should you try to?

Similarly, you are on holiday and someone tells you a museum is open till 04:30. Can you go to dinner first?

I guess that a main question is what kind of query is more frequent: "What time is it now in X", or "At what time is X where I am now?". I thought the former was way more frequent, but now, I do not know anymore.

Maybe the best thing to do is to drop absolute references altogether. IMO, "Shall we meet in 3 hours" is easier for handling across timezone discussions, and will work equally well for "in a different timezone than the one I am used to".

Of course, your SMS/ping/twitter/email client would have to automatically count down such timers for you.