7 ms·

If we started today from scratch, I think timezones wouldn't be set by towns but by arbitrary numbers or letters (something like "+8:00 DST-2") Having to chose

If we started today from scratch, I think timezones wouldn't be set by towns but by arbitrary numbers or letters (something like "+8:00 DST-2") Having to chose a single town on each timezone is just bound to be problematic whatever the criteria are, and it would also mean endless arguments about changing timezone names when the chosen town doesn't meet these criteria anymore.

sam_lowry_ 5y ago
Er... Imagine selecting among those alphanumeric identifiers at system install time.
- makeitdouble 5y ago
  Is it worse than looking at a world map and trying to check the representative town on the same zone as yours ? In a way it would help a lot to expand geographic knowledge, especially if the europe and US were all mapped to somewhere in the south hemisphere.
arp242 5y ago
Storing it purely as a numerical offset isn't enough, because you need to know the location. Does DST apply? When does DST start? Did DST exist in 1971? Will DST exist next year? Will it be DST next week? I'm not sure what you intended with "DST-2" in your proposed format exactly, but you really need a database for these things since there isn't a universal agreement on these things. Maybe there ought to be, but there isn't so we'll have to deal with that. Plus countries change timezones. I can set it to "+8:00" and in two years my country changes its timezone and now the stored information (and thus my time) is incorrect. We also need to know on which date the change takes effect, because showing the wrong time for tomorrow or next week would otherwise show the wrong time. I actually store timezones as "<country>.<zone>". e.g. NL.Europe/Amsterdam. This is because users select the country first in the UI (rather than a zone), and this way it will always be clear which country the user selected. It would be confusing at best, and potentially offensive, to show a different country later.
masklinn 5y ago
> If we started today from scratch, I think timezones wouldn't be set by towns but by arbitrary numbers or letters (something like "+8:00 DST-2") That is exactly the wrongest thing to do, because your version makes it impossible to plan future local events. It would essentially be a completely useless intermediate layer between something very similar to the current timezones and the "absolute" times below.

sam_lowry_ 5y ago

Er... Imagine selecting among those alphanumeric identifiers at system install time.

makeitdouble 5y ago
Is it worse than looking at a world map and trying to check the representative town on the same zone as yours ? In a way it would help a lot to expand geographic knowledge, especially if the europe and US were all mapped to somewhere in the south hemisphere.

arp242 5y ago

Storing it purely as a numerical offset isn't enough, because you need to know the location. Does DST apply? When does DST start? Did DST exist in 1971? Will DST exist next year? Will it be DST next week? I'm not sure what you intended with "DST-2" in your proposed format exactly, but you really need a database for these things since there isn't a universal agreement on these things. Maybe there ought to be, but there isn't so we'll have to deal with that. Plus countries change timezones. I can set it to "+8:00" and in two years my country changes its timezone and now the stored information (and thus my time) is incorrect. We also need to know on which date the change takes effect, because showing the wrong time for tomorrow or next week would otherwise show the wrong time. I actually store timezones as "<country>.<zone>". e.g. NL.Europe/Amsterdam. This is because users select the country first in the UI (rather than a zone), and this way it will always be clear which country the user selected. It would be confusing at best, and potentially offensive, to show a different country later.

masklinn 5y ago

> If we started today from scratch, I think timezones wouldn't be set by towns but by arbitrary numbers or letters (something like "+8:00 DST-2") That is exactly the wrongest thing to do, because your version makes it impossible to plan future local events. It would essentially be a completely useless intermediate layer between something very similar to the current timezones and the "absolute" times below.