5 ms·

To be, uh, fair, I didn't actually know where Abidjan was (the example given in this article). The urban area has a population of over five million, compared to

by geofft 5y ago

To be, uh, fair, I didn't actually know where Abidjan was (the example given in this article). The urban area has a population of over five million, compared to greater Reykjavik's population of under a quarter million - a bit smaller than the small city where I grew up, even! So while I do agree that backwards compatibility is important, and I hope the technical changes are resolved in a way that seems to match the consensus of everyone else on the list besides the TZ Coordinator... if one were constructing a time zone database from first principles these days, I'm not sure what the argument would be to prefer Reykjavik as the synechdoche for the time zone to Abidjan, besides "It's in Europe."

oh_sigh 5y ago
How about "The city in the zone that the most people in the world could point to on a globe"?
- makeitdouble 5y ago
  My chaotic side would love yearly elections or competition to decide which town will be the winner for each timezones every year. Bonus points if it's an online poll where the game becomes hacking as much votes as possible without getting caught.
- izacus 5y ago
  Forcing the whole globe to choose the same city is pretty much opposite of equity and fairness - people from e.g. Africa, South America will know of different cities than people from North America or Northen Europe so I don't quite understand why you'd all force them into the same crutch. Computers are supposed to make lives easier for people and since we can somehow bring ads to everyone in the world, we can probably also extend timezone databases to include most of the world.
  - lifthrasiir 5y ago
    Replace "equity and fairness" with "consistency" then it makes much more sense. I think Paul Eggert keeps using those words mainly because the patch was originally triggered by external complaints, but "consistency" better explains the gist of the situation. There are two ways to make the tzdb more consistent: either merging time zones that are alike since 1970, or splitting time zones as much as possible. The latter was the pre-2014 approach and much harder to maintain (after all, should we split time zones just for newly discovered pre-1970 time zone differences?), so the tzdb has gradually switched to the former for a decade. This patch is just a continuation of this ongoing switch. Alternatively, it might be possible to keep the latter approach but limit the scope so that the maintenance remains doable. For example the tzdb can forgo textual time zone identifiers and declare that downstream projects are responsible for the mapping to the external world (and thus politics). However that would make the tzdb much less useful. The current policy does seem to maximize the value of the database without much trouble (that is, limited to a minor drama) and any change to the policy requires a serious consideration about that. In comparison the forking proposal by Colebourne is at best naive.
makeitdouble 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") 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

by geofft 5y ago

oh_sigh 5y ago

How about "The city in the zone that the most people in the world could point to on a globe"?

makeitdouble 5y ago
My chaotic side would love yearly elections or competition to decide which town will be the winner for each timezones every year. Bonus points if it's an online poll where the game becomes hacking as much votes as possible without getting caught.
izacus 5y ago
Forcing the whole globe to choose the same city is pretty much opposite of equity and fairness - people from e.g. Africa, South America will know of different cities than people from North America or Northen Europe so I don't quite understand why you'd all force them into the same crutch. Computers are supposed to make lives easier for people and since we can somehow bring ads to everyone in the world, we can probably also extend timezone databases to include most of the world.
- lifthrasiir 5y ago
  Replace "equity and fairness" with "consistency" then it makes much more sense. I think Paul Eggert keeps using those words mainly because the patch was originally triggered by external complaints, but "consistency" better explains the gist of the situation. There are two ways to make the tzdb more consistent: either merging time zones that are alike since 1970, or splitting time zones as much as possible. The latter was the pre-2014 approach and much harder to maintain (after all, should we split time zones just for newly discovered pre-1970 time zone differences?), so the tzdb has gradually switched to the former for a decade. This patch is just a continuation of this ongoing switch. Alternatively, it might be possible to keep the latter approach but limit the scope so that the maintenance remains doable. For example the tzdb can forgo textual time zone identifiers and declare that downstream projects are responsible for the mapping to the external world (and thus politics). However that would make the tzdb much less useful. The current policy does seem to maximize the value of the database without much trouble (that is, limited to a minor drama) and any change to the policy requires a serious consideration about that. In comparison the forking proposal by Colebourne is at best naive.

makeitdouble 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") 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