Why do timezones include location?

Viewed 53

I'm working on a website interface and I see a drop down that says "Change your timezone". When I click on that drop down, I see a list like this:

CST - America/Costa Rica (GMT -06:00)
CST - America/El Salvador (GMT -06:00)
CST - America/Guatamala (GMT -06:00)
etc...
EDT - America/New York (GMT -04:00)
EDT - America/Nipigon (GMT -04:00)
EDT - America/Toronto (GMT -04:00)
etc...

I vaguely recall working with some PHP libraries and Javascript date libraries that also require you to specify location like America/Toronto and America/New York in addition to specifying the timezone (eg. GMT offset or UTC offset).

My question is why are locations like America/Toronto or America/New York required when working with timezones? Will there ever be multiple political jurisdictions in the same timezone that show different times?

3 Answers

This is the naming scheme of the tzdb. Their explanation:

Each main entry in the database represents a timezone for a set of civil-time clocks that have all agreed since 1970. Timezones are typically identified by continent or ocean and then by the name of the largest city within the region containing the clocks. For example, America/New_York represents most of the US eastern time zone; America/Phoenix represents most of Arizona, which uses mountain time without daylight saving time (DST); America/Detroit represents most of Michigan, which uses eastern time but with different DST rules in 1975; and other entries represent smaller regions like Starke County, Indiana, which switched from central to eastern time in 1991 and switched back in 2006.

Wikipedia has some discussion on the correspondence with national borders:

Country names are not used in this scheme, primarily because they would not be robust, owing to frequent political and boundary changes. The names of large cities tend to be more permanent. However, the database maintainers attempt to include at least one zone for every ISO 3166-1 alpha-2 country code, and a number of user interfaces to the database take advantage of this. Additionally there is a desire to keep locations geographically compact so that any future time zone changes do not split locations into different time zones.

There have been some exceptions: the former countries of North Yemen and South Yemen were both covered by Asia/Aden, and East and West Germany were both covered by Europe/Berlin.

They can certainly cross sub-national boundaries. For instance the US states of Utah, New Mexico, Wyoming, Montana and Colorado (and parts of some others) are covered by America/Denver.

At least one thing is that some locations have daylight saving which changes UTC offset depending on time of year.

Properly time zone are regional zones with same time rules. If you want to go to past dates, you will find that New York and Toronto were using different times. So it it correct that time zone is a location string. If you remember when you installed a new computer, it ask the time zone (continent/city) and not a time offset.

Then you have Eastern (standard) time (EST). This is just an offset compared to GMT/UTC. Some US states may change the time (from one to the other, e.g. in boundary zones). Some states/countries may choose not to use EDT (daylight). But you keep the zone. For this reason it is better to use the notation: "time zone": geographic and possibly fix, "time offset" the difference of time compared to GMT at that time. (and this may changes because of daylight times, but also because political reasons). Usually we use "time offsets" for larger geographic entities, because it is easier to compare times (now but not for historical or future times).

But so. Time offset are well defined (not really: same letters may be used for different times, usually in different continents). Time zone requires a database which it should be updated regularly: rules changes.

Related