4 ms·

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~

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 15y ago
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.
- azernik 15y ago
  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 15y ago
    > 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.
- vacri 15y ago
  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.
- rmc 15y ago
  Just store all the dates and times in UTC, then convert to local time
mikeash 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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 15y ago
        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.

jarin 15y ago

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.

azernik 15y ago
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 15y ago
  > 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.
vacri 15y ago
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.
rmc 15y ago
Just store all the dates and times in UTC, then convert to local time

mikeash 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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.