Converting cities to tz identifiers (tangent)
This is a bit of a rambling tangent, so sorry. I recently had to find tz zones for ~100 American cities, and the process did not go quite as smoothly as I had expected. I figured that a review of theory.html and tz-link.html would tell me the best way to do this, and it didn't really work out that way. The result was that I found myself just reading the "northamererica" file and knocking out the states that were unambiguous, and then checking the rest against timeanddate.com or time.is. It seems wrong that this appeared to be the easiest approach at this scale, so I wonder what others would suggest (with the benefit of hindsight). And then, in most cases, converting the zones via "backward" to the "US/Eastern" American political because doing so seemed more "stable." * I was expecting theory.html to give me a little more guidance on the "right" way to do this. As best as I can tell, the "right" (no pun intended) answer is that I should geolocate each city to longitude/latitude (using some unspecified resource, which seems fine), then use one of the datasets or tools at https://data.iana.org/time-zones/tz-link.html#boundaries to convert those locations to zones. This seemed a bit much. * I was also a little surprised to not find someone with a handy list of United States states and territory mappings to tz identifiers (for those cases where the state/territory/district uniquely mapped to a tzid). Other than the comments in "northamerica" (which are not quite as structured as one might like, but are pretty good). * Then I was faced with the question of what the most stable identifier to use was. For instance, take Boston, Massachusetts. I could record it as America/New_York, or as US/Eastern. For instance, at some point in the future, either Boston or New York might exit the Eastern time zone. Cases: Case 1: If that New York exited and Boston didn't, picking US/Eastern would clearly be the more stable choice. Case 2: And if Boston exited and New York didn't, it wouldn't matter which I chose, I'd have to update my mapping when Boston moved. Case 3: If New York and Boston both exited US/Eastern and went the same way, then America/New_York would be the better choice. Case 4: If New York and Boston both exited US/Eastern and did different things, it's not clear which is the better choice, but similar to Case 2. Lather rinse repeat for 50 states + some territories and DC. My conclusion was that in general, for most locations, the US/* ("backward") form seemed the better choice. (Both Massachusetts and Florida seem to have current proposals to depart US/Eastern and America/New_York.) * So, I'm curious if this anecdote triggers any reactions. Did I miss an obvious way to address this more simply? Is it horrible to have made use of third party websites that lack any sort of auditable authority but are probably correct anyhow. Is this just not a problem that people have to solve with any frequency? Does someone (Paul?) want to convince me that it's Wrong to use the "backward" zones, for the narrow (but common) case of United States of America cities? Thanks for any thoughts. --jhawk@mit.edu John Hawkinson
John Hawkinson said:
* I was expecting theory.html to give me a little more guidance on the "right" way to do this. As best as I can tell, the "right" (no pun intended) answer is that I should geolocate each city to longitude/latitude (using some unspecified resource, which seems fine), then use one of the datasets or tools at https://data.iana.org/time-zones/tz-link.html#boundaries to convert those locations to zones. This seemed a bit much.
Unfortunately reality can be like that.
* I was also a little surprised to not find someone with a handy list of United States states and territory mappings to tz identifiers (for those cases where the state/territory/district uniquely mapped to a tzid). Other than the comments in "northamerica" (which are not quite as structured as one might like, but are pretty good).
I don't know enough about US time history to be able to comment.
* Then I was faced with the question of what the most stable identifier to use was. For instance, take Boston, Massachusetts. I could record it as America/New_York, or as US/Eastern. For instance, at some point in the future, either Boston or New York might exit the Eastern time zone. Cases:
Case 1: If that New York exited and Boston didn't, picking US/Eastern would clearly be the more stable choice.
[...] The correct answer is that if New York and Boston ever do different things, no matter what they are, then the existing America/New_York will be forked into two (or more) zones. New York will stay in that one. I can't say what the other one(s) will be, because it will depend on the details of the change. It might be America/Boston but might not.
Did I miss an obvious way to address this more simply?
Is it horrible to have made use of third party websites that lack any sort of auditable authority but are probably correct anyhow.
Is there an official source for which parts of the US are *currently* in which time zones (including different summer time transitions)? If there isn't, then you can see the problem. If there is, then is there such a source for every date from 1970 onwards? If so, then that could be converted to form what you want. If not, then you can see the problem. Of course, that doesn't address places that de facto use a different time to the de jure one. Eucla in Australia is the obvious example: legally it's on UTC+8 the whole year round, but in practice it's UTC+8:45 and the TZ database recognizes that.
Does someone (Paul?) want to convince me that it's Wrong to use the "backward" zones, for the narrow (but common) case of United States of America cities?
I'm not sure what the point of them is, so I can't comment. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
Clive D.W. Feather <clive@davros.org> wrote on Tue, 20 Feb 2018 at 17:59:28 +0000 in <20180220175928.GB49012@davros.org>:
The correct answer is that if New York and Boston ever do different things, no matter what they are, then the existing America/New_York will be forked into two (or more) zones. New York will stay in that one.
That's a correct statement, but it's not an answer to the question of whether it's better to put a city in US/Eastern or America/New_York. It's certainly not a "correct answer" to the question asked. (It's also, kind of, obvious and was not what was being queried.)
Is there an official source for which parts of the US are *currently* in which time zones (including different summer time transitions)?
Sure. Although it's something like 57 different sources (combination of each state/territory's government plus the the US Code). Although tracking down the provenance accurately might be a lot of effort, we can generally assume that claims in the comments of "northamerica" are accurate.
If there is, then is there such a source for every date from 1970 onwards? If so, then that could be converted to form what you want.
Well, again, no, that's not my point. Let's presume the tz database has accurately captured the relevant transitions in the United States since 1970. As such, the relevant zones in "northamerica" and "australasia" are sufficient. This isn't about creating zones. It's just about mapping or tagging them. It also turns out that for my purposes, history was not terribly important.
Does someone (Paul?) want to convince me that it's Wrong to use the "backward" zones, for the narrow (but common) case of United States of America cities?
I'm not sure what the point of them is, so I can't comment.
For one thing, they reflect how the state and federal governments describe their zones. They are the common language both of the citizens on the ground and also legal instruments. --jhawk@mit.edu John Hawkinson
geonames.org cities list has tz-zones as a field of their db On 2018-02-20 12:46, John Hawkinson wrote:
This is a bit of a rambling tangent, so sorry.
I recently had to find tz zones for ~100 American cities, and the process did not go quite as smoothly as I had expected.
I figured that a review of theory.html and tz-link.html would tell me the best way to do this, and it didn't really work out that way.
The result was that I found myself just reading the "northamererica" file and knocking out the states that were unambiguous, and then checking the rest against timeanddate.com or time.is. It seems wrong that this appeared to be the easiest approach at this scale, so I wonder what others would suggest (with the benefit of hindsight).
And then, in most cases, converting the zones via "backward" to the "US/Eastern" American political because doing so seemed more "stable."
* I was expecting theory.html to give me a little more guidance on the "right" way to do this. As best as I can tell, the "right" (no pun intended) answer is that I should geolocate each city to longitude/latitude (using some unspecified resource, which seems fine), then use one of the datasets or tools at https://data.iana.org/time-zones/tz-link.html#boundaries to convert those locations to zones. This seemed a bit much.
* I was also a little surprised to not find someone with a handy list of United States states and territory mappings to tz identifiers (for those cases where the state/territory/district uniquely mapped to a tzid). Other than the comments in "northamerica" (which are not quite as structured as one might like, but are pretty good).
* Then I was faced with the question of what the most stable identifier to use was. For instance, take Boston, Massachusetts. I could record it as America/New_York, or as US/Eastern. For instance, at some point in the future, either Boston or New York might exit the Eastern time zone. Cases:
Case 1: If that New York exited and Boston didn't, picking US/Eastern would clearly be the more stable choice.
Case 2: And if Boston exited and New York didn't, it wouldn't matter which I chose, I'd have to update my mapping when Boston moved.
Case 3: If New York and Boston both exited US/Eastern and went the same way, then America/New_York would be the better choice.
Case 4: If New York and Boston both exited US/Eastern and did different things, it's not clear which is the better choice, but similar to Case 2.
Lather rinse repeat for 50 states + some territories and DC.
My conclusion was that in general, for most locations, the US/* ("backward") form seemed the better choice.
(Both Massachusetts and Florida seem to have current proposals to depart US/Eastern and America/New_York.)
* So, I'm curious if this anecdote triggers any reactions.
Did I miss an obvious way to address this more simply?
Is it horrible to have made use of third party websites that lack any sort of auditable authority but are probably correct anyhow.
Is this just not a problem that people have to solve with any frequency?
Does someone (Paul?) want to convince me that it's Wrong to use the "backward" zones, for the narrow (but common) case of United States of America cities?
Thanks for any thoughts.
--jhawk@mit.edu John Hawkinson
--
I¹ve always used Geonames for this kind of query. For example for Boston MASS http://api.geonames.org/timezoneJSON?formatted=true&username=demo&style=ful l&lat=42.358056&lng=-71.063611 { "sunrise": "2018-02-20 06:34", "lng": -71.063611, "countryCode": "US", "gmtOffset": -5, "rawOffset": -5, "sunset": "2018-02-20 17:22", "timezoneId": "America/New_York", "dstOffset": -4, "countryName": "United States", "time": "2018-02-20 13:39", "lat": 42.358056 } Or you can download one of the citiesXXXX.zip from http://download.geonames.org/export/dump/ On 20/02/2018, 17:46, "tz on behalf of John Hawkinson" <tz-bounces@iana.org on behalf of jhawk@MIT.EDU> wrote:
This is a bit of a rambling tangent, so sorry.
I recently had to find tz zones for ~100 American cities, and the process did not go quite as smoothly as I had expected.
I figured that a review of theory.html and tz-link.html would tell me the best way to do this, and it didn't really work out that way.
The result was that I found myself just reading the "northamererica" file and knocking out the states that were unambiguous, and then checking the rest against timeanddate.com or time.is. It seems wrong that this appeared to be the easiest approach at this scale, so I wonder what others would suggest (with the benefit of hindsight).
And then, in most cases, converting the zones via "backward" to the "US/Eastern" American political because doing so seemed more "stable."
* I was expecting theory.html to give me a little more guidance on the "right" way to do this. As best as I can tell, the "right" (no pun intended) answer is that I should geolocate each city to longitude/latitude (using some unspecified resource, which seems fine), then use one of the datasets or tools at https://data.iana.org/time-zones/tz-link.html#boundaries to convert those locations to zones. This seemed a bit much.
* I was also a little surprised to not find someone with a handy list of United States states and territory mappings to tz identifiers (for those cases where the state/territory/district uniquely mapped to a tzid). Other than the comments in "northamerica" (which are not quite as structured as one might like, but are pretty good).
* Then I was faced with the question of what the most stable identifier to use was. For instance, take Boston, Massachusetts. I could record it as America/New_York, or as US/Eastern. For instance, at some point in the future, either Boston or New York might exit the Eastern time zone. Cases:
Case 1: If that New York exited and Boston didn't, picking US/Eastern would clearly be the more stable choice.
Case 2: And if Boston exited and New York didn't, it wouldn't matter which I chose, I'd have to update my mapping when Boston moved.
Case 3: If New York and Boston both exited US/Eastern and went the same way, then America/New_York would be the better choice.
Case 4: If New York and Boston both exited US/Eastern and did different things, it's not clear which is the better choice, but similar to Case 2.
Lather rinse repeat for 50 states + some territories and DC.
My conclusion was that in general, for most locations, the US/* ("backward") form seemed the better choice.
(Both Massachusetts and Florida seem to have current proposals to depart US/Eastern and America/New_York.)
* So, I'm curious if this anecdote triggers any reactions.
Did I miss an obvious way to address this more simply?
Is it horrible to have made use of third party websites that lack any sort of auditable authority but are probably correct anyhow.
Is this just not a problem that people have to solve with any frequency?
Does someone (Paul?) want to convince me that it's Wrong to use the "backward" zones, for the narrow (but common) case of United States of America cities?
Thanks for any thoughts.
--jhawk@mit.edu John Hawkinson
I'll give a few of my answers, speaking as an observer on this list.
On Feb 20, 2018, at 12:46 PM, John Hawkinson <jhawk@mit.edu> wrote:
This is a bit of a rambling tangent, so sorry.
I recently had to find tz zones for ~100 American cities, and the process did not go quite as smoothly as I had expected. ... And then, in most cases, converting the zones via "backward" to the "US/Eastern" American political because doing so seemed more "stable."
I would not recommend that. "backward" exists, as the name suggests, only for backward compatibility with old naming conventions. The primary definitions for the zones are the continent/city names, so America/New_York.
* I was expecting theory.html to give me a little more guidance on the "right" way to do this. As best as I can tell, the "right" (no pun intended) answer is that I should geolocate each city to longitude/latitude (using some unspecified resource, which seems fine), then use one of the datasets or tools at https://data.iana.org/time-zones/tz-link.html#boundaries to convert those locations to zones. This seemed a bit much.
It may seem harder than necessary, but that may be because you haven't fully realized the depths of confusion that politicians will go to.
* I was also a little surprised to not find someone with a handy list of United States states and territory mappings to tz identifiers (for those cases where the state/territory/district uniquely mapped to a tzid). Other than the comments in "northamerica" (which are not quite as structured as one might like, but are pretty good).
Poking around Indiana will give you a good idea of why this stuff is harder than you might expect. There you will find some per-county rules, and at some point in time county A might match county B while at another point in history it uses different rules. So yes, the answer really is as hard as it seems to be. 1. For each defined done (America/*) find the boundaries of that zone, in one of the published shapefile databases. 2. For each city you're interested in, use its coordinates to match against the shape data from step 1 to learn what zone it is in.
* Then I was faced with the question of what the most stable identifier to use was. For instance, take Boston, Massachusetts. I could record it as America/New_York, or as US/Eastern. For instance, at some point in the future, either Boston or New York might exit the Eastern time zone. Cases: ... My conclusion was that in general, for most locations, the US/* ("backward") form seemed the better choice.
(Both Massachusetts and Florida seem to have current proposals to depart US/Eastern and America/New_York.)
Well, US/x is just a link to America/y, for suitable y. So there isn't any actual difference. The real problem is this: If some of the places in an existing zone change their rules to differ from those of the rest of the zone, the new definition will have two zones where there used to be just one. Presumably, one of the two will retain its existing name; the other will get a new name assigned according to the naming conventions given. Consider a slightly stranger example: suppose that NY leaves the current Eastern timezone. In that case, I would expect there to be a a America/New_York zone with the NEW rule for NY (only) and the existing America/New_York ("Eastern time") zone would get a new name because NYC is no longer in it. That might be America/Philadelphia; probably not America/Boston given the sizes of those cities. So to answer the question of the most stable identifier to use -- there isn't one. You can definitely associate today's zone name for each city with that city. But that doesn't help predict what might happen next year, because you'd just be guessing what politicians might do and in general that isn't feasible. paul
Paul.Koning@dell.com <Paul.Koning@dell.com> wrote on Tue, 20 Feb 2018 at 20:10:33 +0000 in <4FEED0AD-A1BA-4D23-B461-CB07F0F85045@dell.com>:
I would not recommend that. "backward" exists, as the name suggests, only for backward compatibility with old naming conventions.
I'm not sure we've made such a statement of deprecation. I think a lot of people use the US/* style, even though it's not what the tz db prefers. I think a lot of people would be up-in-arms if those identifiers were deprecated anytime in foreseeable life of the project (measured in decades). But perhaps I am wrong (or too conservative).
It may seem harder than necessary, but that may be because you haven't fully realized the depths of confusion that politicians will go to.
Nah, I'm well aware of it. But the fact of the matter is, in the United States, for non-historical timestamps, very few of the gotchas pop up. For sure, there are states that have multiple zones in them, but that's not (at least in my view) a "gotcha."
Poking around Indiana will give you a good idea of why this stuff is harder than you might expect. There you will find some per-county rules, and at some point in time county A might match county B while at another point in history it uses different rules.
See above. If we're dealing with present day (as I am), this is not a real concern.
So yes, the answer really is as hard as it seems to be.
I think you mistake me.
Well, US/x is just a link to America/y, for suitable y. So there isn't any actual difference.
That's objectively false. The difference is what happens in the future when tz database breaks the link.
The real problem is this: If some of the places in an existing zone change their rules to differ from those of the rest of the zone, the new definition will have two zones where there used to be just one.
Correct. And that's why it matters what I choose. And that's also why my inclination is to choose the US/* form.
Consider a slightly stranger example [...]
It's because that's such an unlikely case that I'm not particularly worried about it. In my situation, I'm making a reasonable judgment between two choices that are unlikely to matter, but if they do, I'd like to choose the most maintainable and understandable choice that reduces future maintenance. Strange examples are good to be aware of, but aren't directly helpful.
So to answer the question of the most stable identifier to use -- there isn't one.
Oh, that's not true. There are lots of reasons to make choices about which identifier to use, and lots of ways to define stability. I offered some of my reasoning, and I'm curious what other people think (especially the argument for avoiding the "backward" zones, which I've always thought to be relatively weak arguments in the United States, but a lot stronger elsewhere).
But that doesn't help predict what might happen next year, because you'd just be guessing what politicians might do and in general that isn't feasible.
False. Just because we cannot accurately predict the future does not mean we may not attempt it, and any choice in this space (America/New_York or US/Eastern) is such a prediction. We can't do it with perfect confidence, but certainly can do it, and arguably we must make such a choice. (Of course, we can make the choice by Rule instead of by evaluation of stability, and our Rule might be "Don't use the backward id's because *secret magic reason*." But it's still a choice.) --jhawk@mit.edu John Hawkinson
If what you want is that if what you *want* is "the time zone in Boston", you need to store something that means "the time zone in Boston" rather than eagerly doing the lookup. You'll have to look up the mapping between Boston <-> America/* every time because the tzdb zones do *not* represent rules for a given geographical region, they represent historically coherent rulesets. The main problem is that doing this is *way* more complicated than picking a single time zone from the enumerable list of tzdb zones and storing *that*. If you happen to be in one of the cities the zone is named after, you'll get the right thing, but otherwise all bets are off. It's further complicated by the fact that even the geographical location <-> time zone ruleset is upset by the existence of things like Asia/Urumqi, where whether you use the ruleset is a cultural rather than geographical question. In any case, I sympathize with the question of "US/Eastern" vs. "America/New_York". It does seem like there are times where the time zone you want is "the US Eastern time zone", regardless of whether that represents the time in New York or not, in which case you *can* eagerly map to "US/Eastern", whereas if you want "the current time in <some city>", for the most part you *cannot* eagerly map to a given time zone. This leads to the perverse result that there are times when it makes sense to store "US/Eastern", but "America/New_York" is usually at best an approximation of what you actually want (leaving aside the "coincidence" case of time in New York). Best, Paul On 02/20/2018 04:36 PM, John Hawkinson wrote:
Paul.Koning@dell.com <Paul.Koning@dell.com> wrote on Tue, 20 Feb 2018 at 20:10:33 +0000 in <4FEED0AD-A1BA-4D23-B461-CB07F0F85045@dell.csom>:
I would not recommend that. "backward" exists, as the name suggests, only for backward compatibility with old naming conventions.
I'm not sure we've made such a statement of deprecation. I think a lot of people use the US/* style, even though it's not what the tz db prefers. I think a lot of people would be up-in-arms if those identifiers were deprecated anytime in foreseeable life of the project (measured in decades). But perhaps I am wrong (or too conservative).
It may seem harder than necessary, but that may be because you haven't fully realized the depths of confusion that politicians will go to.
Nah, I'm well aware of it. But the fact of the matter is, in the United States, for non-historical timestamps, very few of the gotchas pop up. For sure, there are states that have multiple zones in them, but that's not (at least in my view) a "gotcha."
Poking around Indiana will give you a good idea of why this stuff is harder than you might expect. There you will find some per-county rules, and at some point in time county A might match county B while at another point in history it uses different rules.
See above. If we're dealing with present day (as I am), this is not a real concern.
So yes, the answer really is as hard as it seems to be.
I think you mistake me.
Well, US/x is just a link to America/y, for suitable y. So there isn't any actual difference.
That's objectively false. The difference is what happens in the future when tz database breaks the link.
The real problem is this: If some of the places in an existing zone change their rules to differ from those of the rest of the zone, the new definition will have two zones where there used to be just one.
Correct. And that's why it matters what I choose. And that's also why my inclination is to choose the US/* form.
Consider a slightly stranger example [...]
It's because that's such an unlikely case that I'm not particularly worried about it. In my situation, I'm making a reasonable judgment between two choices that are unlikely to matter, but if they do, I'd like to choose the most maintainable and understandable choice that reduces future maintenance. Strange examples are good to be aware of, but aren't directly helpful.
So to answer the question of the most stable identifier to use -- there isn't one.
Oh, that's not true. There are lots of reasons to make choices about which identifier to use, and lots of ways to define stability. I offered some of my reasoning, and I'm curious what other people think (especially the argument for avoiding the "backward" zones, which I've always thought to be relatively weak arguments in the United States, but a lot stronger elsewhere).
But that doesn't help predict what might happen next year, because you'd just be guessing what politicians might do and in general that isn't feasible.
False. Just because we cannot accurately predict the future does not mean we may not attempt it, and any choice in this space (America/New_York or US/Eastern) is such a prediction. We can't do it with perfect confidence, but certainly can do it, and arguably we must make such a choice. (Of course, we can make the choice by Rule instead of by evaluation of stability, and our Rule might be "Don't use the backward id's because *secret magic reason*." But it's still a choice.)
--jhawk@mit.edu John Hawkinson
On Feb 20, 2018, at 2:07 PM, Paul Ganssle <pganssle@gmail.com> wrote:
In any case, I sympathize with the question of "US/Eastern" vs. "America/New_York". It does seem like there are times where the time zone you want is "the US Eastern time zone",
What is meant by "the US Eastern time zone"? The zone that, barring adjustments such as Daylight Savings Time, is 5 hours west of UTC - and that may include locations that do make DST adjustments and locations that don't? If so, then all that asking for "the US Eastern time zone" will get you is "5 hours west of UTC"; it won't get you any rules for adjustments, because not all locations in the Eastern time zone will necessarily follow the same rules. Indianapolis, for example, has an interesting time zone history: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER Rule Indianapolis 1941 only - Jun 22 2:00 1:00 D Rule Indianapolis 1941 1954 - Sep lastSun 2:00 0 S Rule Indianapolis 1946 1954 - Apr lastSun 2:00 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Indiana/Indianapolis -5:44:38 - LMT 1883 Nov 18 12:15:22 -6:00 US C%sT 1920 -6:00 Indianapolis C%sT 1942 -6:00 US C%sT 1946 -6:00 Indianapolis C%sT 1955 Apr 24 2:00 -5:00 - EST 1957 Sep 29 2:00 -6:00 - CST 1958 Apr 27 2:00 -5:00 - EST 1969 -5:00 US E%sT 1971 -5:00 - EST 2006 -5:00 US E%sT which includes periods where it was in the Eastern time zone but didn't do DST. *Currently*, it does DST, but it didn't do so in the past and it, or other locations, could conceivably do so in the future. If we ask about the US Mountain time zone, instead, there are *currently* locations in that zone that do DST and locations that don't. The tzdb is not currently the place to ask about "the US Eastern time zone", because it doesn't have any mechanism to ask what the UTC offset of the "US Eastern time zone" is. You can ask about the current un-adjusted UTC offset for a given location in the Eastern time zone (which might be different from the un-adjusted UTC offset for that location in the past, as per the above information for Indianapolis).
regardless of whether that represents the time in New York or not, in which case you *can* eagerly map to "US/Eastern", whereas if you want "the current time in <some city>", for the most part you *cannot* eagerly map to a given time zone.
Remember, the things that are identified by tz database identifiers are *not* time zones, the derivation of the "tz" part of "tz database" notwithstanding. They're regions that may have, over time, been in more than one time zone (see above).
What is meant by "the US Eastern time zone"?
I think the colloquial meaning applies. The case I'm thinking of would be things like a hotline which advertises its hours in "Eastern time" rather than the time zone of a specific city, or a distributed team following roughly US time zone rules that schedules their meetings in "Eastern time" even though the members of the team are in various locations. This is mooted if US/Eastern is defined forever after as being linked to America/New_York, but if it continues to carry the colloquial meaning, there *are* cases where it makes sense to eagerly resolve it rather than save as a mapping. Additionally I suppose there is a question of whether there exists a stable, dependable source of mappings between these abstract zones and the tzdb keys that apply at to them, given that the ones in tzdb exist only in backward/ On February 20, 2018 11:04:11 PM UTC, Guy Harris <guy@alum.mit.edu> wrote:
On Feb 20, 2018, at 2:07 PM, Paul Ganssle <pganssle@gmail.com> wrote:
In any case, I sympathize with the question of "US/Eastern" vs. "America/New_York". It does seem like there are times where the time zone you want is "the US Eastern time zone",
What is meant by "the US Eastern time zone"? The zone that, barring adjustments such as Daylight Savings Time, is 5 hours west of UTC - and that may include locations that do make DST adjustments and locations that don't?
If so, then all that asking for "the US Eastern time zone" will get you is "5 hours west of UTC"; it won't get you any rules for adjustments, because not all locations in the Eastern time zone will necessarily follow the same rules. Indianapolis, for example, has an interesting time zone history:
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER Rule Indianapolis 1941 only - Jun 22 2:00 1:00 D Rule Indianapolis 1941 1954 - Sep lastSun 2:00 0 S Rule Indianapolis 1946 1954 - Apr lastSun 2:00 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Indiana/Indianapolis -5:44:38 - LMT 1883 Nov 18 12:15:22 -6:00 US C%sT 1920 -6:00 Indianapolis C%sT 1942 -6:00 US C%sT 1946 -6:00 Indianapolis C%sT 1955 Apr 24 2:00 -5:00 - EST 1957 Sep 29 2:00 -6:00 - CST 1958 Apr 27 2:00 -5:00 - EST 1969 -5:00 US E%sT 1971 -5:00 - EST 2006 -5:00 US E%sT
which includes periods where it was in the Eastern time zone but didn't do DST. *Currently*, it does DST, but it didn't do so in the past and it, or other locations, could conceivably do so in the future. If we ask about the US Mountain time zone, instead, there are *currently* locations in that zone that do DST and locations that don't.
The tzdb is not currently the place to ask about "the US Eastern time zone", because it doesn't have any mechanism to ask what the UTC offset of the "US Eastern time zone" is. You can ask about the current un-adjusted UTC offset for a given location in the Eastern time zone (which might be different from the un-adjusted UTC offset for that location in the past, as per the above information for Indianapolis).
regardless of whether that represents the time in New York or not, in which case you *can* eagerly map to "US/Eastern", whereas if you want "the current time in <some city>", for the most part you *cannot* eagerly map to a given time zone.
Remember, the things that are identified by tz database identifiers are *not* time zones, the derivation of the "tz" part of "tz database" notwithstanding. They're regions that may have, over time, been in more than one time zone (see above).
On Feb 20, 2018, at 3:27 PM, Paul G <paul@ganssle.io> wrote:
What is meant by "the US Eastern time zone"?
I think the colloquial meaning applies. The case I'm thinking of would be things like a hotline which advertises its hours in "Eastern time" rather than the time zone of a specific city, or a distributed team following roughly US time zone rules that schedules their meetings in "Eastern time" even though the members of the team are in various locations.
Fortunately, every US location in the Eastern time zone observes DST, so the city doesn't currently matter. But what happens if somebody decides to schedule a meeting in "Mountain time" some time between 2 o’clock antemeridian on the second Sunday of March and 2 o’clock antemeridian on the first Sunday of November? That wouldn't suffice; you'd either have to explicitly schedule it for "Mountain standard time" or "Mountain daylight time", or treat it as implied that Arizona doesn't count and "Mountain time" is "Mountain daylight time" during that period.
This is mooted if US/Eastern is defined forever after as being linked to America/New_York, but if it continues to carry the colloquial meaning, there *are* cases where it makes sense to eagerly resolve it rather than save as a mapping.
Resolve it to what?
Additionally I suppose there is a question of whether there exists a stable, dependable source of mappings between these abstract zones and the tzdb keys that apply at to them,
tzdb ids don't correspond to time zones, they correspond to tz regions. The boundaries of time zones shift over time; the only way in which the boundaries of tz regions should shift is that a given tz region splits into two or more regions if some part or parts of that tz region end up in a different time zone due to a time zone boundary shift, decide to change their observance of DST, or something such as that. "The US Eastern time zone" doesn't inherently map to any particular tzdb region. It could be mapped to the tzdb region that's 1) currently in that time zone, 2) has been outside that region for the shortest period of time (including "it's been there ever since standard time was established") and 3) covers the largest area, or population, amongst regions that match on the first two criteria. That would map it to America/New_York, and "the US Central time zone" would map to America/Chicago, and "the US Mountain time zone" would map to America/Denver (sorry, Arizona!), and "the US Pacific time zone" would map to America/Los_Angeles. The resulting tz region would not necessarily be the *only* tz region that's in the time zone in question, however.
given that the ones in tzdb exist only in backward/
...and the ones in backward/ don't necessarily correspond to the *entire* zone with the name; US/Mountain doesn't apply to Mountain time in Arizona, for example.
What is meant by "the US Eastern time zone"?
I think the colloquial meaning applies. The case I'm thinking of would be things like a hotline which advertises its hours in "Eastern time" rather than the time zone of a specific city, or a distributed team following roughly US time zone rules that schedules their meetings in "Eastern time" even though the members of the team are in various locations.
Fortunately, every US location in the Eastern time zone observes DST, so the city doesn't currently matter.
But what happens if somebody decides to schedule a meeting in "Mountain time" some time between 2 o’clock antemeridian on the second Sunday of March and 2 o’clock antemeridian on the first Sunday of November? That wouldn't suffice; you'd either have to explicitly schedule it for "Mountain standard time" or "Mountain daylight time", or treat it as implied that Arizona doesn't count and "Mountain time" is "Mountain daylight time" during that period.
In my experience, usage in everyday speech is generally that Arizona is said to spend the winters in Mountain time and the summers in Pacific time, rather than spending the whole year in Mountain standard time. So if you say "Mountain time" in the summer, people understand that to be UTC-6, even when dealing with people in Arizona. This is kind of fuzzy definition is insufficient for a project like tzdb, but in a user interface it might well be the best understood option. - Adam
Well, for the US anyway, the names "Eastern", "Mountain", etc. are explicitly provided by 15 USC § 263, and their boundaries are defined in 49 CFR Part 71. So there is indeed a very specific and exact meaning of "the US Eastern time zone". Also, a few folks mentioned GeoNames. That is certainly one arbitrary source of boundary data, but it's unclear as to its sourcing methodology. Personally, I find the approach used by Even Siroky's Time Zone Boundary Builder project (https://github.com/evansiroky/timezone-boundary-builder) to be much more viable, as it uses Open Street Map as its primary source. OSM has a good blend of reliable sources and crowd sourcing, so IMHO it aligns well with the TZDB mindset. Other mechanisms are available here: https://stackoverflow.com/questions/16086962/how-to-get-a-time-zone-from-a-l... Note that unlike the US, time zone borders in other parts of the world are much fuzzier. Depending on your politics, you may disagree about a country boundary and thus also disagree about the local time for a particular point along that boundary. This has been discussed ad nauseam already, with many examples... -Matt ________________________________ From: tz <tz-bounces@iana.org> on behalf of Adam Vartanian via tz <tz@iana.org> Sent: Wednesday, February 21, 2018 2:27 AM To: Guy Harris Cc: tz@iana.org Subject: Re: [tz] Converting cities to tz identifiers (tangent)
What is meant by "the US Eastern time zone"?
I think the colloquial meaning applies. The case I'm thinking of would be things like a hotline which advertises its hours in "Eastern time" rather than the time zone of a specific city, or a distributed team following roughly US time zone rules that schedules their meetings in "Eastern time" even though the members of the team are in various locations.
Fortunately, every US location in the Eastern time zone observes DST, so the city doesn't currently matter. But what happens if somebody decides to schedule a meeting in "Mountain time" some time between 2 o’clock antemeridian on the second Sunday of March and 2 o’clock antemeridian on the first Sunday of November? That wouldn't suffice; you'd either have to explicitly schedule it for "Mountain standard time" or "Mountain daylight time", or treat it as implied that Arizona doesn't count and "Mountain time" is "Mountain daylight time" during that period. In my experience, usage in everyday speech is generally that Arizona is said to spend the winters in Mountain time and the summers in Pacific time, rather than spending the whole year in Mountain standard time. So if you say "Mountain time" in the summer, people understand that to be UTC-6, even when dealing with people in Arizona. This is kind of fuzzy definition is insufficient for a project like tzdb, but in a user interface it might well be the best understood option. - Adam
Considering that USA is just a consumer of TMZ political decisions all over the world, and that China is the biggest economy, why would this group that is responsible for keeping the database related to each country decision in the world, why would we care about a carrot colour president of a capitalist "country" that depends of a communist country. It fells quite stupid to follow the second economy that would break off the first communist economy just decide to stop to provide any board/chip or whatever to think about. Does this group even make sense without understanding this? On 21 Feb 2018 6:26 pm, "Matt Johnson" <mj1856@hotmail.com> wrote:
Well, for the US anyway, the names "Eastern", "Mountain", etc. are explicitly provided by 15 USC § 263, and their boundaries are defined in 49 CFR Part 71. So there is indeed a very specific and exact meaning of "the US Eastern time zone".
Also, a few folks mentioned GeoNames. That is certainly one arbitrary source of boundary data, but it's unclear as to its sourcing methodology. Personally, I find the approach used by Even Siroky's Time Zone Boundary Builder project (https://github.com/evansiroky/timezone-boundary-builder) to be much more viable, as it uses Open Street Map as its primary source. OSM has a good blend of reliable sources and crowd sourcing, so IMHO it aligns well with the TZDB mindset.
Other mechanisms are available here: https://stackoverflow. com/questions/16086962/how-to-get-a-time-zone-from-a- location-using-latitude-and-longitude-coordinates
Note that unlike the US, time zone borders in other parts of the world are much fuzzier. Depending on your politics, you may disagree about a country boundary and thus also disagree about the local time for a particular point along that boundary. This has been discussed ad nauseam already, with many examples...
-Matt
------------------------------ *From:* tz <tz-bounces@iana.org> on behalf of Adam Vartanian via tz < tz@iana.org> *Sent:* Wednesday, February 21, 2018 2:27 AM *To:* Guy Harris *Cc:* tz@iana.org *Subject:* Re: [tz] Converting cities to tz identifiers (tangent)
What is meant by "the US Eastern time zone"?
I think the colloquial meaning applies. The case I'm thinking of would be things like a hotline which advertises its hours in "Eastern time" rather than the time zone of a specific city, or a distributed team following roughly US time zone rules that schedules their meetings in "Eastern time" even though the members of the team are in various locations.
Fortunately, every US location in the Eastern time zone observes DST, so the city doesn't currently matter.
But what happens if somebody decides to schedule a meeting in "Mountain time" some time between 2 o’clock antemeridian on the second Sunday of March and 2 o’clock antemeridian on the first Sunday of November? That wouldn't suffice; you'd either have to explicitly schedule it for "Mountain standard time" or "Mountain daylight time", or treat it as implied that Arizona doesn't count and "Mountain time" is "Mountain daylight time" during that period.
In my experience, usage in everyday speech is generally that Arizona is said to spend the winters in Mountain time and the summers in Pacific time, rather than spending the whole year in Mountain standard time. So if you say "Mountain time" in the summer, people understand that to be UTC-6, even when dealing with people in Arizona.
This is kind of fuzzy definition is insufficient for a project like tzdb, but in a user interface it might well be the best understood option.
- Adam
On 2018-02-21 03:27, Adam Vartanian via tz wrote:
What is meant by "the US Eastern time zone"? I think the colloquial meaning applies. The case I'm thinking of would be things like a hotline which advertises its hours in "Eastern time" rather than the time zone of a specific city, or a distributed team following roughly US time zone rules that schedules their meetings in "Eastern time" even though the members of the team are in various locations. Fortunately, every US location in the Eastern time zone observes DST, so the city doesn't currently matter. But what happens if somebody decides to schedule a meeting in "Mountain time" some time between 2 o’clock antemeridian on the second Sunday of March and 2 o’clock antemeridian on the first Sunday of November? That wouldn't suffice; you'd either have to explicitly schedule it for "Mountain standard time" or "Mountain daylight time", or treat it as implied that Arizona doesn't count and "Mountain time" is "Mountain daylight time" during that period. In my experience, usage in everyday speech is generally that Arizona is said to spend the winters in Mountain time and the summers in Pacific time, rather than spending the whole year in Mountain standard time. So if you say "Mountain time" in the summer, people understand that to be UTC-6, even when dealing with people in Arizona. This is kind of fuzzy definition is insufficient for a project like tzdb, but in a user interface it might well be the best understood option.
Indeed I am sure that, as in Saskatchewan, Canada, which stays on CST year round, while local time stamps are probably marked CST, national schedules are as if on MDT, and in Arizona, USA, on PDT, as GMT-n is not a common notation. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
<<On Tue, 20 Feb 2018 16:36:55 -0500, John Hawkinson <jhawk@MIT.EDU> said:
Paul.Koning@dell.com <Paul.Koning@dell.com> wrote on Tue, 20 Feb 2018 at 20:10:33 +0000 in <4FEED0AD-A1BA-4D23-B461-CB07F0F85045@dell.com>:
I would not recommend that. "backward" exists, as the name suggests, only for backward compatibility with old naming conventions.
I'm not sure we've made such a statement of deprecation. I think a lot of people use the US/* style, even though it's not what the tz db prefers. I think a lot of people would be up-in-arms if those identifiers were deprecated anytime in foreseeable life of the project (measured in decades). But perhaps I am wrong (or too conservative).
When I was the timezone maintainer for FreeBSD, I made a deliberate decision not to use the backward file (unless the user rebuilt their system after changing a make variable). I believe the current maintainer has continued this policy, so there's at least one downstream platform that does not support the old names and has not done so for about two decades. The zone.tab file (which FreeBSD's timezone chooser uses) does not reference the "backward" zones as I recall. -GAWollman
On 2018-02-20 17:30:53 (-0500), Garrett Wollman wrote:
On Tue, 20 Feb 2018 16:36:55 -0500, John Hawkinson <jhawk@MIT.EDU> said:
Paul.Koning@dell.com <Paul.Koning@dell.com> wrote on Tue, 20 Feb 2018:
I would not recommend that. "backward" exists, as the name suggests, only for backward compatibility with old naming conventions.
I'm not sure we've made such a statement of deprecation. I think a lot of people use the US/* style, even though it's not what the tz db prefers. I think a lot of people would be up-in-arms if those identifiers were deprecated anytime in foreseeable life of the project (measured in decades). But perhaps I am wrong (or too conservative).
When I was the timezone maintainer for FreeBSD, I made a deliberate decision not to use the backward file (unless the user rebuilt their system after changing a make variable). I believe the current maintainer has continued this policy
I suppose that by the "you touched it last so now you own it" principle, the current maintainer is me. I am indeed continuing your policy. FreeBSD doesn't use the tzdb build process directly (we have our own Makefile) and we only install the current zones.
so there's at least one downstream platform that does not support the old names and has not done so for about two decades. The zone.tab file (which FreeBSD's timezone chooser uses) does not reference the "backward" zones as I recall.
Correct. I have been thinking about using zone1970.tab instead (which we do not currently even install) but I haven't gotten around to it yet. (I also have some work in progress to bring tzcode up to a more recent version but ... turns out "time" is not only difficult to describe but also difficult to find!) Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
On 02/20/2018 09:46 AM, John Hawkinson wrote:
in general, for most locations, the US/* ("backward") form seemed the better choice.
It depends on how portable you want to be. Some implementations do not use the 'backward' file, so TZ='US/Eastern' does not work for them. FreeBSD is one such, or at least it was the last time I recall checking; see Garrett Wollman's email <https://mm.icann.org/pipermail/tz/2008-May/014941.html>. So, in practice I would say TZ='America/New_York' is more portable than TZ='US/Eastern'. If New York ever switches to Atlantic time (unlikely but conceivable given the current state of US politics), we'll link some other location to US/Eastern in the 'backward' file. Although it's not now clear what that other location would be (it'd depend on what part of the US switches), one candidate would be America/Indiana/Indianapolis. This is because if Jacksonville, Philadelphia and New York all switch to Atlantic time, then Indianapolis could well be the largest remaining city observing US Eastern time. This should amuse those of us who recall the history of UT offsets in Indiana.
For the USA, does city mean the metro area or the city proper? The next five metros in Eastern time after NYC are Washington, Philadelphia, Miami, Boston; for cities proper, it's Philadelphia, Jacksonville, (Indianapolis), Columbus, Charlotte. Envoyé de mon iPad
Le 20 févr. 2018 à 17:25, Paul Eggert <eggert@cs.ucla.edu> a écrit :
If New York ever switches to Atlantic time (unlikely but conceivable given the current state of US politics), we'll link some other location to US/Eastern in the 'backward' file. Although it's not now clear what that other location would be (it'd depend on what part of the US switches), one candidate would be America/Indiana/Indianapolis. This is because if Jacksonville, Philadelphia and New York all switch to Atlantic time, then Indianapolis could well be the largest remaining city observing US Eastern time. This should amuse those of us who recall the history of UT offsets in Indiana.
Insert Atlanta immediately after Miami. Envoyé de mon iPad
Le 20 févr. 2018 à 17:43, J Andrew Lipscomb <silverpie2@mac.com> a écrit :
For the USA, does city mean the metro area or the city proper? The next five metros in Eastern time after NYC are Washington, Philadelphia, Miami, Boston; for cities proper, it's Philadelphia, Jacksonville, (Indianapolis), Columbus, Charlotte.
Envoyé de mon iPad
Le 20 févr. 2018 à 17:25, Paul Eggert <eggert@cs.ucla.edu> a écrit :
If New York ever switches to Atlantic time (unlikely but conceivable given the current state of US politics), we'll link some other location to US/Eastern in the 'backward' file. Although it's not now clear what that other location would be (it'd depend on what part of the US switches), one candidate would be America/Indiana/Indianapolis. This is because if Jacksonville, Philadelphia and New York all switch to Atlantic time, then Indianapolis could well be the largest remaining city observing US Eastern time. This should amuse those of us who recall the history of UT offsets in Indiana.
On 02/20/2018 02:43 PM, J Andrew Lipscomb wrote:
For the USA, does city mean the metro area or the city proper?
I expect it'd partly depend on whether the area is likely to split time zones. For some metro areas (Denver, say) that's unlikely, for others (New York City metro area, which crosses state-line boundaries) it would be more of an issue. Cities have split time zones in the past (Asia/Nicosia comes to mind) so this issue isn't entirely theoretical.
On 2018-02-20 16:05, Paul Eggert wrote:
On 02/20/2018 02:43 PM, J Andrew Lipscomb wrote:
For the USA, does city mean the metro area or the city proper? I expect it'd partly depend on whether the area is likely to split time zones. For some metro areas (Denver, say) that's unlikely, for others (New York City metro area, which crosses state-line boundaries) it would be more of an issue. Cities have split time zones in the past (Asia/Nicosia comes to mind) so this issue isn't entirely theoretical.
There are numerous candidates for political spats overriding common sense and custom: https://en.wikipedia.org/wiki/List_of_divided_cities -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
(multiple replies inline) Guy Harris <guy@alum.mit.edu> wrote on Tue, 20 Feb 2018 at 15:04:11 -0800 in <91FA6B60-4729-4B8D-80F9-2E79851A8D76@alum.mit.edu>:
What is meant by "the US Eastern time zone"? The zone that, barring adjustments such as Daylight Savings Time, is 5 hours west of UTC - and that may include locations that do make DST adjustments and locations that don't?
I think it generally means the region as defined in 15 USC 260a et seq.
If so, then all that asking for "the US Eastern time zone" will get you is "5 hours west of UTC"; it won't get you any rules for adjustments, because not all locations in the Eastern time zone will necessarily follow the same rules.
Well, that's certainly not true in the tz project. It'll get you America/New_York, which gets you the NYC rules. (Now, maybe that is what's wanted, maybe it's not. In my case particular case, it's fine, because I'm not concerned with history.)
The tzdb is not currently the place to ask about "the US Eastern time zone",
That is not the question I'm asking, however:
because it doesn't have any mechanism to ask what the UTC offset of the "US Eastern time zone" is.
Sure it does. The answer is just more approximate than some people (you?) might like, but is perfectly fine for others' purposes (mine own). Paul Eggert <eggert@cs.ucla.edu> wrote on Tue, 20 Feb 2018 at 14:25:49 -0800 in <5b1e840e-b46d-9406-820a-754304e48e60@cs.ucla.edu>:
It depends on how portable you want to be. Some implementations do
Portability is an intersting question. Yet another thing to balance with what I called "stability." Like most people, I'm at present only concerned with portability to the systems I care about, which doesn't have to include FreeBSD right now, although I am definitely annoyed at Garrett's unilateral decision to make my preferred form less portable than I would like it to be :)
If New York ever switches to Atlantic time (unlikely but conceivable given the current state of US politics), we'll link some other location to US/Eastern in the 'backward' file. Although it's not now clear what that other location would be (it'd depend on what part of the US switches), one candidate would be America/Indiana/Indianapolis.
I'm pretty sure that's not a reasonable candidate :) I can't tell if you're joking, but even if the rules in Theory happen to allow or recommend that choice, I'm pretty sure we would revise them to discourage choosing a candidate that has a history that is so radically divergant from the vast majority of the geographical area in the zone. --jhawk@mit.edu John Hawkinson
Like Toronto :) On 2018-02-20 18:23, John Hawkinson wrote:
I can't tell if you're joking, but even if the rules in Theory happen to allow or recommend that choice, I'm pretty sure we would revise them to discourage choosing a candidate that has a history that is so radically divergant from the vast majority of the geographical area in the zone.
--jhawk@mit.edu John Hawkinson
--
On 02/20/2018 03:23 PM, John Hawkinson wrote:
Although it's not now clear what that other location would be (it'd depend on what part of the US switches), one candidate would be America/Indiana/Indianapolis. I'm pretty sure that's not a reasonable candidate:)
I can't tell if you're joking, but even if the rules in Theory happen to allow or recommend that choice, I'm pretty sure we would revise them to discourage choosing a candidate that has a history that is so radically divergant from the vast majority of the geographical area in the zone.
I was partly joking (because I think it unlikely), but partly not. As Guy Harris wrote, the whole idea of TZ='US/Eastern' is reasonably fuzzy and there's certainly no expectation of a particular time zone history for it. Because US/Eastern is intended for current and future timestamps for a "generic" location in the US Eastern time zone, it cannot be correct for all timestamps between 1970 and now. So, although we would keep a backward-compatibility link for US/Eastern even if New York City moved to the Atlantic time zone, there's no guarantee about which US city (if any) would be referred to by any new US/Eastern backward-compatibility link.
On Tue 2018-02-20T15:41:05-0800 Paul Eggert hath writ:
As Guy Harris wrote, the whole idea of TZ='US/Eastern' is reasonably fuzzy and there's certainly no expectation of a particular time zone history for it.
I think a US lawyer would disagree that there is any fuzziness for the "time zone" US/Eastern *if* that were defined as in 15USC260 thru 15USC263. The Uniform Time Act of 1966 https://www.gpo.gov/fdsys/pkg/STATUTE-80/pdf/STATUTE-80-Pg107.pdf was passed 1966-04-13 and specified that all local times in the US were to be set forward on last Sunday April and back on last Sunday October. That was in effect at the tz cutoff of 1970-01-01 and though the spring/fall dates have subsequently changed there is never any ambiguity about the meaning in the US. The fuzziness arises because US/Eastern is a "tz region" as defined by tzdb, not a "time zone" as defined by US law. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On Feb 20, 2018, at 4:12 PM, Steve Allen <sla@ucolick.org> wrote:
On Tue 2018-02-20T15:41:05-0800 Paul Eggert hath writ:
As Guy Harris wrote, the whole idea of TZ='US/Eastern' is reasonably fuzzy and there's certainly no expectation of a particular time zone history for it.
I think a US lawyer would disagree that there is any fuzziness for the "time zone" US/Eastern *if* that were defined as in 15USC260 thru 15USC263. The Uniform Time Act of 1966 https://www.gpo.gov/fdsys/pkg/STATUTE-80/pdf/STATUTE-80-Pg107.pdf was passed 1966-04-13 and specified that all local times in the US were to be set forward on last Sunday April and back on last Sunday October.
...unless some State decides to exempt itself as, for example, the Grand Canyon State currently does. Some parts of the Mountain time zone change local times in that fashion (as modified by subsequent laws, so no longer April and October), other parts do not.
(replies inline to 3 of Guy Harris's messages): Guy Harris <guy@alum.mit.edu> wrote on Tue, 20 Feb 2018 at 17:06:07 -0800 in <957A2A1C-43D9-4B8D-B45A-824472015A9A@alum.mit.edu>:
I think it generally means the region as defined in 15 USC 260a et seq.
There is no tz region that could handle the US Mountain time zone, however, because Arizona, which is in the Mountain time zone, does not observe DST, and Colorado, which is also in the Mountain time zone, does observe DST.
I would assert that, for colloquial purposes at least, Arizona is not part of the US Mountain time zone, because it elects not to follow DST, even though it would otherwise be so considered, regionally or boundary-wise (or within the meaning of 15 USC §261) (This is more apparent when reviewing 49 CFR 71, which, by regulation, codifies the boundaries of hte zones).
There's also a tzdb id "EST" which is 5 hours retarded from UTC all year around and a tzdb id "EST5EDT" which is "5 hours retarded from
Red herring.
In what way does asking for "the US Eastern time zone" get you America/New_York in the tz project? What part of the tz database tie America/New_York, and no other tz region, to "the US Eastern time zone"?
The "backward" file. But since you know this, I'm puzzled what your point is? pb3:tz jhawk$ grep US/Eastern backward Link America/New_York US/Eastern
Sure it does. The answer is just more approximate than some people (you?) might like, but is perfectly fine for others' purposes (mine own).
So what is this mechanism?
Eh? As you said yourself: "You can ask about the current un-adjusted UTC offset for a given location in the Eastern time zone (which might be different from the un-adjusted UTC offset for that location in the past, as per the above information for Indianapolis)." I feel as if I'm talking past you, though? Guy Harris <guy@alum.mit.edu> wrote on Tue, 20 Feb 2018 at 17:23:23 -0800 in <FA109B84-3ED6-4744-B970-EC2616EAB0CB@alum.mit.edu>:
But what happens if somebody decides to schedule a meeting in "Mountain time" some time between 2 o’clock antemeridian on the second Sunday of March and 2 o’clock antemeridian on the first Sunday of November? That wouldn't suffice; you'd either have to explicitly schedule it for "Mountain standard time" or "Mountain daylight time", or treat it as implied that Arizona doesn't count and "Mountain time" is "Mountain daylight time" during that period.
Yes. You treat it that Arizona doesn't count as "Mountain time." It has it's own rule set.
"The US Eastern time zone" doesn't inherently map to any particular tzdb region. It could be mapped to the tzdb region that's 1) currently in that time zone, 2) has been outside that region for the shortest period of time (including "it's been there ever since standard time was established") and 3) covers the largest area, or population, amongst regions that match on the first two criteria.
I think, essentially, (1) and (3) are the same. The "US Eastern time zone" is coterminus with the America/New_York boundary (I think). A more interesting case:
That would map it to America/New_York, and "the US Central time zone" would map to America/Chicago,
Here, the "US Central time zone" is not coterminus with America/Chicago, since the America/Chicago boundary excludes southeast Indiana (and various other things), because of history. So, yes, "US Central time zone" isn't the same as US/Central (which is America/Chicago) because of such historical issues. But is this is problem or concern? Not for most users, and not for people scheduling things in the future.
...and the ones in backward/ don't necessarily correspond to the *entire* zone with the name; US/Mountain doesn't apply to Mountain time in Arizona, for example.
This is all true, but I am somewhat of a loss as to why this is an interesting fact to highlight in this discussion? Maybe I'm guilty of monopolizing the thread and focusing on the part I raised and the thread has moved on, though? Guy Harris <guy@alum.mit.edu> wrote on Tue, 20 Feb 2018 at 17:28:36 -0800 in <7A98670F-82B9-4B1C-8F0D-16C7A5E50820@alum.mit.edu> (quoting Steve Allen):
I think a US lawyer would disagree that there is any fuzziness for the "time zone" US/Eastern *if* that were defined as in 15USC260 thru 15USC263. The Uniform Time Act of 1966
...unless some State decides to exempt itself as, for example, the Grand Canyon State currently does. Some parts of the Mountain time zone change local times in that fashion (as modified by subsequent laws, so no longer April and October), other parts do not.
Well, that exemption is permitted pursuant to 15 USC §260a(a)(1). Of course, if we want to be pedantic, Steve was only talking about US/Eastern, where there currently are not such exemptions. But if we extend his comment to refer to the western zones, then yes, there's a bit of fuzziness. Not for the lawyers, but for the rest of us. The lawyers would disagree on fuzziness within the meaning of the statute -- there the plain language is clear that states that opt out of DST are still within their statutory time zones -- but rather the rules we follow are different. That is, Arizona doesn't follow the US/Mountain rules, it follows the US/Arizona (or America/Phoenix, if you must). So when someone says "mountain time," the fuzziness is whether they are including Arizona or not. Colloquially, I'd say we generally think they're not. (So, sure, my comment of 18:23:14 Eastern (see that?) where I said "generally [as] 15 USC 260a et seq" was insufficiently precise to address your concern. Perhaps I should have chosen a wiggle-word more wiggly than "generally," on the assumption you meant a region/zone more complicated than Eastern). But I don't see what this has to do with the questions raised of how to one maps states to zones and whether to use US/* -style "backward" names or not. I mapped Arizona to US/Arizona, not US/Mountain, and it solved my problems. One could quibble about whether a state to tz mapping there should go to US/Mountain or America/Phoenix, but I'm not sure I see why we'd quibble about anything else. --jhawk@mit.edu John Hawkinson
On Feb 20, 2018, at 6:24 PM, John Hawkinson <jhawk@MIT.EDU> wrote:
Guy Harris <guy@alum.mit.edu> wrote on Tue, 20 Feb 2018 at 17:06:07 -0800 in <957A2A1C-43D9-4B8D-B45A-824472015A9A@alum.mit.edu>:
I think it generally means the region as defined in 15 USC 260a et seq.
There is no tz region that could handle the US Mountain time zone, however, because Arizona, which is in the Mountain time zone, does not observe DST, and Colorado, which is also in the Mountain time zone, does observe DST.
I would assert that, for colloquial purposes at least, Arizona is not part of the US Mountain time zone, because it elects not to follow DST, even though it would otherwise be so considered, regionally or boundary-wise (or within the meaning of 15 USC §261) (This is more apparent when reviewing 49 CFR 71, which, by regulation, codifies the boundaries of hte zones).
So, for your purposes, the zone in question is the part of the zone that hasn't opted out of DST. This means, of course, that not all cities in the XXX time zone, as defined by the US Code, can be mapped to US/XXX.
In what way does asking for "the US Eastern time zone" get you America/New_York in the tz project? What part of the tz database tie America/New_York, and no other tz region, to "the US Eastern time zone"?
The "backward" file. But since you know this,
I'm aware that there is a backwards-compatibility alias for America/New_York named US/Eastern, and there are similar aliases with names corresponding to the names of other US time zones, but, as far as I know, that's not intended to be an indication that the file in question corresponds to "the Eastern time zone", either in the legal or colloquial sense, so anybody depending on that is depending on something not in the contract for the tzdb.
I'm puzzled what your point is?
That the tzdb doesn't anywhere deliberately say "here's the Eastern time zone".
Sure it does. The answer is just more approximate than some people (you?) might like, but is perfectly fine for others' purposes (mine own).
So what is this mechanism?
Eh? As you said yourself: "You can ask about the current un-adjusted UTC offset for a given location in the Eastern time zone (which might be different from the un-adjusted UTC offset for that location in the past, as per the above information for Indianapolis)."
...which requires that you either: 1) find a location in the Eastern time zone and map it to a tzdb region and use that or 2) rely on US/Eastern existing and mapping to a location in the Eastern time zone - the first of those is not part of the tzdb contract, although, in practice, if it exists, it'd be silly for it not to map to such a location (although, of course, the DST rules for "US/Eastern" will not necessarily correspond to the rules for all DST-observing places in the Eastern time zone in the future).
That would map it to America/New_York, and "the US Central time zone" would map to America/Chicago,
Here, the "US Central time zone" is not coterminus with America/Chicago, since the America/Chicago boundary excludes southeast Indiana (and various other things), because of history.
So, yes, "US Central time zone" isn't the same as US/Central (which is America/Chicago) because of such historical issues. But is this is problem or concern? Not for most users, and not for people scheduling things in the future.
If you assume time zone/DST rule stability in the future, yeah, you could associate all cities that are in the Central time zone and that observe DST with {America/Chicago, US/Central}. But if you assume time zone/DST rule stability in the future, you assume that no locations that are currently in America/Chicago will leave it, so you might as well use America/Chicago, as it would be no less stable than US/Central. If, however, you don't wish to assume time zone/DST rule stability in the future, then you must assume that any static map from locations to tzdb regions may break in the future, so you must use some form of dynamic mapping and, if you cache any mappings so you don't have to do the mapping every time, you must be prepared to discard any cached mappings if any changes are made that affect some of those mappings. In that case, again, if you're caching mappings, a mapping to US/Central is no better than a mapping to America/Chicago - if America/Chicago were to split, no matter which of the two resulting regions US/Central links to, there's probably going to be *some* city for which the cached mapping no longer applies, so you might as well use America/Chicago. (And if you're not caching mappings, stability doesn't matter, because you'll only be using the mapping once and re-generating it every time.) And that pertains to all of the backward/ aliases. I.e., to go back to your original email:
* Then I was faced with the question of what the most stable identifier to use was. For instance, take Boston, Massachusetts. I could record it as America/New_York, or as US/Eastern. For instance, at some point in the future, either Boston or New York might exit the Eastern time zone. Cases:
Case 1: If that New York exited and Boston didn't, picking US/Eastern would clearly be the more stable choice.
Case 2: And if Boston exited and New York didn't, it wouldn't matter which I chose, I'd have to update my mapping when Boston moved.
Case 3: If New York and Boston both exited US/Eastern and went the same way, then America/New_York would be the better choice.
Case 4: If New York and Boston both exited US/Eastern and did different things, it's not clear which is the better choice, but similar to Case 2.
Lather rinse repeat for 50 states + some territories and DC.
My conclusion was that in general, for most locations, the US/* ("backward") form seemed the better choice.
To decide which is the better choice for a given locale, you'd need to decide whether that locale is likely to leave the tz region it's currently in. By "My conclusion was that in general, for most locations, the US/* ("backward") form seemed the better choice." do you mean that you looked at the locations and concluded that most of them are not likely to exit their time zone, with "their time zone" meaning "their time zone *and* choice of whether to observe DST or not"? Furthermore, in the case of a region split, there will probably be some locales for which US/{Zonename} is the worse choice and some locales for which America/{US_City} is the worse choice, so, if you want to be prepared for a region split, you'll have to be prepared to deal with breakage no matter which one you choose - i.e., there will be locations for which the choice you make requires a change, no matter *what* choice you make.
Guy Harris <guy@alum.mit.edu> wrote on Tue, 20 Feb 2018 at 19:53:07 -0800 in <B46E0D0E-6484-4F09-A89C-E0957783FDE3@alum.mit.edu>:
I'm aware that there is a backwards-compatibility alias for America/New_York named US/Eastern, and there are similar aliases with names corresponding to the names of other US time zones, but, as far as I know, that's not intended to be an indication that the file in question corresponds to "the Eastern time zone", either in the legal or colloquial sense, so anybody depending on that is depending on something not in the contract for the tzdb.
I think it's intended to be an indication in the colloquial sense, and that people like me would complain loudly if a future update decided to break this.
...which requires that you either: ... 2) rely on US/Eastern existing and mapping to a location in the Eastern time zone - the first of those is not part of the tzdb contract, although, in practice, if it exists, it'd be silly for it not to map to such a location (although, of course, the DST rules for "US/Eastern" will not necessarily correspond to the rules for all DST-observing places in the Eastern time zone in the future).
I'm pretty comfortable with this assumption.
But if you assume time zone/DST rule stability in the future, you assume that no locations that are currently in America/Chicago will leave it, so you might as well use America/Chicago, as it would be no less stable than US/Central.
"You could do A, but you might as well do B" is not a compelling argument for doing B over A. And furthermore:
If, however, you don't wish to assume time zone/DST rule stability in the future, then you must assume that any static map from locations to tzdb regions may break in the future, so you must use some form of dynamic mapping and, if you cache any mappings so you don't have to do the mapping every time, you must be prepared to discard any cached mappings if any changes are made that affect some of those mappings.
I'm not quite sure how we're distinguishing static mapping from dynamic mapping. If by "dynamic mapping" you mean "I update my static mapping file," then sure.
In that case, again, if you're caching mappings, a mapping to US/Central is no better than a mapping to America/Chicago - if America/Chicago were to split, no matter which of the two resulting regions US/Central links to, there's probably going to be *some* city for which the cached mapping no longer applies, so you might as well use America/Chicago.
No, these events do not have equal probabilities. For the cities I care about, my conclusion is that the current lead city of the time zone ("backward" link) is more likely to exit the zone than the city I am mapping from. Or put differently, Boston is more likely to disassociate from New York than it is to disassociate with Eastern time. (But, it turns out, neither of those are the likely case, standing alone. Most likely none of those will happen, but also, if one happens the other is likely to happen too.) An additional point we haven't discussed, but happens to matter to me, is that this mapping list is likely to be looked at by people who aren't familiar with the tz database, and for whom seeing that Boston is associated with US/Eastern is more meaningful and less confusing than seeing Boston is associated with America/New_York. I realize this is a problem the tz database generally tries to pretend to ignore, in the name of politics, and that the US/* formations are specially privileged because most countries don't get that non-city-specific choice (but the US does. How convenient for those of us there.) But it's a realistic consideration for me. I'm not sure why I omitted it from my initial reasoning -- perhaps I managed to bury it subconsciously.
To decide which is the better choice for a given locale, you'd need to decide whether that locale is likely to leave the tz region it's currently in. By "My conclusion was that in general, for most locations, the US/* ("backward") form seemed the better choice." do you mean that you looked at the locations and concluded that most of them are not likely to exit their time zone, with "their time zone" meaning "their time zone *and* choice of whether to observe DST or not"?
Almost. You frame this in absolute probabilities, but the probabilities are all low. I frame this in relative probabilities between 2 events. I concluded that the cities are more likely to diverge from the lead cities of their zone (Boston from New York) than they are to exit their «zone and choice of DST» (as you put it).
Furthermore, in the case of a region split, there will probably be some locales for which US/{Zonename} is the worse choice and some locales for which America/{US_City} is the worse choice, so, if you want to be prepared for a region split, you'll have to be prepared to deal with breakage no matter which one you choose - i.e., there will be locations for which the choice you make requires a change, no matter *what* choice you make.
Agreed. The calculus for me was which was the more likely case, but I did not mean to suggest anyone could rely on such things with any certainty. When the rules change, everybody has to pay attention. As I write this, Paul pointed out an error of mine:
Not really: even inside the US, the US Eastern time zone currently also includes America/Indiana/Indianapolis, America/Indiana/Marengo, America/Indiana/Vincennes, America/Indiana/Petersburg, America/Indiana/Winamac, America/Indiana/Vevay, America/Kentucky/Louisville, America/Kentucky/Monticello, and America/Detroit. And several locations outside the US are currently in the same time zone, e.g., America/Nassau.
Whoops, Somehow I managed to convince myself that those Indiana and Kentucky were in Central Time. Typical east coast biases, I'm afraid :) Please adjust my prior post accordingly [...] --jhawk@mit.edu John Hawkinson
On Feb 20, 2018, at 8:23 PM, John Hawkinson <jhawk@MIT.EDU> wrote:
Guy Harris <guy@alum.mit.edu> wrote on Tue, 20 Feb 2018 at 19:53:07 -0800 in <B46E0D0E-6484-4F09-A89C-E0957783FDE3@alum.mit.edu>:
I'm aware that there is a backwards-compatibility alias for America/New_York named US/Eastern, and there are similar aliases with names corresponding to the names of other US time zones, but, as far as I know, that's not intended to be an indication that the file in question corresponds to "the Eastern time zone", either in the legal or colloquial sense, so anybody depending on that is depending on something not in the contract for the tzdb.
I think it's intended to be an indication in the colloquial sense, and that people like me would complain loudly if a future update decided to break this.
I don't think it's currently intended, by the tzdb maintainers, to be anything other than a backwards-compatibility hack. The name was *originally* chosen as an indication in the colloquial sense, but that doesn't mean it's still part of the contract for the tzdb, so relying on its existence is relying on something the tzdb doesn't guarantee. The name itself is unlikely to change, because there's not much point in changing a backwards-compatibility name, but I don't think the tzdb makes any guarantee where it'll point if, for example, New York City leaves the Eastern time zone or New York State decides not to observe DST, even in the face of complaints.
But if you assume time zone/DST rule stability in the future, you assume that no locations that are currently in America/Chicago will leave it, so you might as well use America/Chicago, as it would be no less stable than US/Central.
"You could do A, but you might as well do B" is not a compelling argument for doing B over A.
"You could do A or B, as they have the same result, and A isn't guaranteed to work, while B is", however, should be a somewhat compelling argument. Doing B will work on FreeBSD, for example, and doing A won't.
And furthermore:
If, however, you don't wish to assume time zone/DST rule stability in the future, then you must assume that any static map from locations to tzdb regions may break in the future, so you must use some form of dynamic mapping and, if you cache any mappings so you don't have to do the mapping every time, you must be prepared to discard any cached mappings if any changes are made that affect some of those mappings.
I'm not quite sure how we're distinguishing static mapping from dynamic mapping. If by "dynamic mapping" you mean "I update my static mapping file," then sure.
In this case, "static mapping" means "a human manually sets up a mapping between cities and tzdb regions, and, to find out what tzdb region to use a city, that mapping is used", and "dynamic mapping" means "the mapping is done by software looking up the city's location in some database that gives a tz region ID, either doing it every time the mapping is needed, or caching the result". So, yeah, you *could* do static mapping and manually update the file. This means you may be taking on a burden that the tzdb maintainers, and maintainers of OSes using the tzdb, may not choose to *possibly* ease by keeping the backward/ links.
In that case, again, if you're caching mappings, a mapping to US/Central is no better than a mapping to America/Chicago - if America/Chicago were to split, no matter which of the two resulting regions US/Central links to, there's probably going to be *some* city for which the cached mapping no longer applies, so you might as well use America/Chicago.
No, these events do not have equal probabilities. For the cities I care about, my conclusion is that the current lead city of the time zone ("backward" link) is more likely to exit the zone than the city I am mapping from. Or put differently, Boston is more likely to disassociate from New York than it is to disassociate with Eastern time.
Why do you conclude this?
(But, it turns out, neither of those are the likely case, standing alone. Most likely none of those will happen, but also, if one happens the other is likely to happen too.)
An additional point we haven't discussed, but happens to matter to me, is that this mapping list is likely to be looked at by people who aren't familiar with the tz database, and for whom seeing that Boston is associated with US/Eastern is more meaningful and less confusing than seeing Boston is associated with America/New_York.
I.e., those people are forced to deal directly with the mapping list, rather than just asking "what time is it in Boston?" or questions such as that?
I realize this is a problem the tz database generally tries to pretend to ignore,
"Ignore" in the sense of "treat it as not in scope for the tzdb", if by "the problem" you mean "the fact that tz region ids aren't intended to be end-user friendly".
in the name of politics,
I've not seen anything to indicate that, for example, we don't provide time zone name-based aliases, or city-name-based aliases, for *political* reasons.
and that the US/* formations are specially privileged because most countries don't get that non-city-specific choice (but the US does. How convenient for those of us there.)
Better stated as "some formations are specially privileged because most countries don't get that non-city-specific choice", given that the US's neighbors to the north and south get them too: Link America/Edmonton Canada/Mountain Link America/Halifax Canada/Atlantic Link America/Regina Canada/Saskatchewan Link America/Toronto Canada/Eastern Link America/Vancouver Canada/Pacific Link America/Whitehorse Canada/Yukon Link America/Winnipeg Canada/Central Link America/St_Johns Canada/Newfoundland Link America/Mazatlan Mexico/BajaSur Link America/Mexico_City Mexico/General Link America/Tijuana Mexico/BajaNorte as do some other countries, some of which don't have multiple zones and thus have backward/ aliases giving names or abbreviations for the countries (although Chile has Chile/Continental and Chile/EasterIsland). So, for *historical* reasons, some countries, including but not limited to the US, have non-city-specific choices; it's not as if this is a case of US maintainers not caring about the rest of the world.
John Hawkinson wrote:
The "US Eastern time zone" is coterminus with the America/New_York boundary (I think).
Not really: even inside the US, the US Eastern time zone currently also includes America/Indiana/Indianapolis, America/Indiana/Marengo, America/Indiana/Vincennes, America/Indiana/Petersburg, America/Indiana/Winamac, America/Indiana/Vevay, America/Kentucky/Louisville, America/Kentucky/Monticello, and America/Detroit. And several locations outside the US are currently in the same time zone, e.g., America/Nassau.
On Feb 20, 2018, at 3:23 PM, John Hawkinson <jhawk@MIT.EDU> wrote:
(multiple replies inline)
Guy Harris <guy@alum.mit.edu> wrote on Tue, 20 Feb 2018 at 15:04:11 -0800 in <91FA6B60-4729-4B8D-80F9-2E79851A8D76@alum.mit.edu>:
What is meant by "the US Eastern time zone"? The zone that, barring adjustments such as Daylight Savings Time, is 5 hours west of UTC - and that may include locations that do make DST adjustments and locations that don't?
I think it generally means the region as defined in 15 USC 260a et seq.
15 USC 260a: https://www.law.cornell.edu/uscode/text/15/260a says (a) Duration of period; State exemption During the period commencing at 2 o’clock antemeridian on the second Sunday of March of each year and ending at 2 o’clock antemeridian on the first Sunday of November of each year, the standard time of each zone established by sections 261 to 264 of this title, as modified by section 265 of this title, shall be advanced one hour and such time as so advanced shall for the purposes of such sections 261 to 264, as so modified, be the standard time of such zone during such period; however, (1) any State that lies entirely within one time zone may by law exempt itself from the provisions of this subsection providing for the advancement of time, but only if that law provides that the entire State (including all political subdivisions thereof) shall observe the standard time otherwise applicable during that period, and (2) any State with parts thereof in more than one time zone may by law exempt either the entire State as provided in (1) or may exempt the entire area of the State lying within any time zone. (b) State laws superseded It is hereby declared that it is the express intent of Congress by this section to supersede any and all laws of the States or political subdivisions thereof insofar as they may now or hereafter provide for advances in time or changeover dates different from those specified in this section. 15 USC 261: https://www.law.cornell.edu/uscode/text/15/261 says For the purpose of establishing the standard time of the United States, the territory of the United States shall be divided into nine zones in the manner provided in this section. Except as provided in section 260a(a) of this title, the standard time of the first zone shall be Coordinated Universal Time retarded by 4 hours; that of the second zone retarded by 5 hours; that of the third zone retarded by 6 hours; that of the fourth zone retarded by 7 hours; that of the fifth zone retarded [1] 8 hours; that of the sixth zone retarded by 9 hours; that of the seventh zone retarded by 10 hours; that of the eighth zone retarded by 11 hours; and that of the ninth zone shall be Coordinated Universal Time advanced by 10 hours. The limits of each zone shall be defined by an order of the Secretary of Transportation, having regard for the convenience of commerce and the existing junction points and division points of common carriers engaged in interstate or foreign commerce, and any such order may be modified from time to time. As used in sections 261 to 264 of this title, the term “interstate or foreign commerce” means commerce between a State, the District of Columbia, the Commonwealth of Puerto Rico, or any possession of the United States and any place outside thereof. 15 USC 263: https://www.law.cornell.edu/uscode/text/15/263 says The standard time of the first zone shall be known and designated as Atlantic standard time; that of the second zone shall be known and designated as eastern standard time; that of the third zone shall be known and designated as central standard time; that of the fourth zone shall be known and designated as mountain standard time; that of the fifth zone shall be known and designated as Pacific standard time; that of the sixth zone shall be known and designated as Alaska standard time; that of the seventh zone shall be known and designated as Hawaii-Aleutian standard time; that of the eighth zone shall be known and designated as Samoa standard time; and that of the ninth zone shall be known as Chamorro standard time. so Eastern standard time is UTC retarded by 5 hours, and, in that time zone, the daylight saving time rules, advancing the time (to UTC retarded by 4 hours) during part of the year, are as specified in 260a *unless* either 1) a state entirely within that zone says "no DST here" or 2) a state in more than one time zone either says "no DST anywhere here" or "no DST in the part that's in one of those time zones". So "US Eastern time" is 5 hours retarded from UTC during the period from 2 o’clock antemeridian on the first Sunday of November to just before 2 o’clock antemeridian on the second Sunday of March of the next year, and may be 5 hours retarded from UTC or 4 hours retarded from UTC during the remaining period, depending on whether you're in a part of that zone that decided not to observe DST. Currently, there are no tz regions that are in the US Eastern time zone where DST is not observed, so America/New_York could be used in the US Eastern time zone if historical information and possible future behavior doesn't matter. There is no tz region that could handle the US Mountain time zone, however, because Arizona, which is in the Mountain time zone, does not observe DST, and Colorado, which is also in the Mountain time zone, does observe DST. There's also a tzdb id "EST" which is 5 hours retarded from UTC all year around and a tzdb id "EST5EDT" which is "5 hours retarded from UTC plus the US DST rules since the beginning of time": # From Arthur David Olson, 2005-12-19 # We generate the files specified below to guard against old files with # obsolete information being left in the time zone binary directory. # We limit the list to names that have appeared in previous versions of # this time zone package. # We do these as separate Zones rather than as Links to avoid problems if # a particular place changes whether it observes DST. # We put these specifications here in the northamerica file both to # increase the chances that they'll actually get compiled and to # avoid the need to duplicate the US rules in another file. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone EST -5:00 - EST Zone MST -7:00 - MST Zone HST -10:00 - HST Zone EST5EDT -5:00 US E%sT Zone CST6CDT -6:00 US C%sT Zone MST7MDT -7:00 US M%sT Zone PST8PDT -8:00 US P%sT
If so, then all that asking for "the US Eastern time zone" will get you is "5 hours west of UTC"; it won't get you any rules for adjustments, because not all locations in the Eastern time zone will necessarily follow the same rules.
Well, that's certainly not true in the tz project. It'll get you America/New_York,
In what way does asking for "the US Eastern time zone" get you America/New_York in the tz project? What part of the tz database tie America/New_York, and no other tz region, to "the US Eastern time zone"?
which gets you the NYC rules. (Now, maybe that is what's wanted, maybe it's not. In my case particular case, it's fine, because I'm not concerned with history.)
The tzdb is not currently the place to ask about "the US Eastern time zone",
That is not the question I'm asking, however:
I wasn't replying to you, I was replying to Paul Ganssle, who had said "It does seem like there are times where the time zone you want is "the US Eastern time zone..."
because it doesn't have any mechanism to ask what the UTC offset of the "US Eastern time zone" is.
Sure it does. The answer is just more approximate than some people (you?) might like, but is perfectly fine for others' purposes (mine own).
So what is this mechanism?
participants (17)
-
Adam Vartanian -
Brian Inglis -
Clive D.W. Feather -
David Patte ₯ -
Garrett Wollman -
Guy Harris -
J Andrew Lipscomb -
John Hawkinson -
Julian Cable -
Matt Johnson -
Pablo Sánchez -
Paul Eggert -
Paul G -
Paul Ganssle -
Paul.Koning＠dell.com -
Philip Paeps -
Steve Allen