19

I have to use the time zone "ET" (Eastern Time). In Java, there is no ZoneId.of("ET").

Which one should I use to represent the "ET" correctly:

ZoneId TIMEZONE_ET = ZoneId.of("US/Eastern");

or

ZoneId TIMEZONE_ET = ZoneId.of("America/New_York");
nimo23
  • 5,170
  • 10
  • 46
  • 75
  • 1
    Did you read the javadoc for ZoneId? It explains where these names come from and their precedence. – Roddy of the Frozen Peas Jun 25 '19 at 16:57
  • There is no "ET" because the "ET" timezone doesn't exist. Maybe [this](https://stackoverflow.com/questions/9863625/difference-between-est-and-america-new-york-time-zones) is what you are looking for. – EDToaster Jun 25 '19 at 16:58
  • the `Eastern Standard Time` is `US/Eastern` I think – Youcef LAIDANI Jun 25 '19 at 16:58
  • I would just use EST for eastern time. Doesn't do daylight savings though – EDToaster Jun 25 '19 at 17:00
  • 3
    @JClassic Not a good idea..if I use that, I have to change 1 times a year.. – nimo23 Jun 25 '19 at 17:03
  • 4
    @YCF_L - No, I'm fairly sure `US/Eastern` is the Eastern zone, which is EST part of the year and EDT part of the year. `ZoneId.of("US/Eastern").getRules().isDaylightSavings(Instant.parse("2019-07-01T00:00:00Z"))` returns `true`, which it wouldn't for Eastern **Standard** Time. – T.J. Crowder Jun 25 '19 at 17:03
  • @YCF_L I also think, but I am not sure..like you:) – nimo23 Jun 25 '19 at 17:04
  • 1
    Unless New York changes its time zone so it's not in the Eastern time zone anymore, I can't see how it would matter. But given *"I have to use the time zone "ET" (Eastern Time)..."* then...that's what I would do. – T.J. Crowder Jun 25 '19 at 17:04
  • Wait. Given the question, I was thinking that you *didn't* want the daylight savings time – EDToaster Jun 25 '19 at 17:05
  • @JClassic I am not sure about that. I only have a time with timezone ET coming from a webservice which I must map to java ZonedDateTime, so I try to find the right ZoneId for it.. – nimo23 Jun 25 '19 at 17:10
  • This is one of those questions that seems like "meh, just do your research" -- until you actually go to do the research, and find it's a bit awkward to find this information. – T.J. Crowder Jun 25 '19 at 17:29
  • 2
    @nimo23 - I've changed my answer in a substantial way since you accepted it. I thought I should call your attention to the fact that `US/Eastern` is old and may be deprecated. See my edits and the other answer to the question. – T.J. Crowder Jun 25 '19 at 18:03
  • @T.J.Crowder thank you very much! I have noticed it. Therefore, I will use the "newer" version which is "America/New_York". Thanks for your effort and the research your answer has..that deserves to be the right answer:) – nimo23 Jun 25 '19 at 18:14
  • 1
    I would argue that you should call your timezone variable "ET" if it doesn't represent "ET". I would name it "TIMEZONE_NEW_YORK", (or "TZ_NEW_YORK", if that's a bit long for your taste) so people are clear that this represents the time zone in New York, in order that it is clear you are using America/New_York (as opposed to, say, EST, which doesn't observe DST), and also so it is clear in the *vastly* unlikely event that NYC changed its time zone which time zone it represents. – Andy Turner Jun 25 '19 at 19:27

3 Answers3

18

Given that your requirement is to use the "Eastern zone," I'd use US/Eastern, but note:

  • It's just a link to America/New_York.
  • This file in Paul Eggert's tz repo says those links are to link "old" names (such as US/Eastern) to current names. "Old" may well mean "deprecated" in this context. Paul Eggert is the TZ Coordinator for IANA's Time Zone list, so this is a clearly canonical source.

Given that, you're probably best off with America/New_York, but given that the change is listed as being from 1993, clearly the old names aren't going away any time soon.

Either will contain the DST rules, etc. On my system, for instance:

var zoneRules = ZoneId.of("US/Eastern").getRules();
System.out.println(zoneRules.isDaylightSavings(Instant.parse("2019-07-01T12:00:00Z"))); // true
System.out.println(zoneRules.isDaylightSavings(Instant.parse("2019-01-01T12:00:00Z"))); // false

Note that noon on July 1st is in DST, and noon on January 1st is not.

More:

In the IANA Time Zone Database files, I've found:

to2050.tzs:

Link America/New_York    US/Eastern

...which suggests the two are aliases (altough ZoneId#equals doesn't return true for them). Also, in northamerica they have:

# US eastern time, represented by New York

with notes citing the relevant law.

So it seems clear to me that at the moment, they're synonymous. It's also clear that US/Eastern is the "old name." Of course, in theory, New York could decide at some point not to be part of the Eastern timezone anymore (perhaps to be closer, time-wise, to the UK and Europe), but that seems really unlikely...

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • 4
    Great answer. The last point is very important. If New York moved to some other time zone (such as Atlantic time), the link from `US/Eastern` would have to be updated to point somewhere else (probably a new zone). Also worth pointing out that there are cities in Indiana and Kentucky *currently* on Eastern time that have deviated into Central time in past years, and they have their own TZDB identifiers. Also consider DST has varied among some of them (ex, Detroit in the 1970s), and that Canada's eastern time is better represented by `America/Toronto`. – Matt Johnson-Pint Jun 26 '19 at 15:56
7

America/New_York

The answer is in the List of tz database time zones: US/Eastern is deprecated and is just a link to America/New_York. So to be sure of future compatibility you should use America/New_York.

Wikipedia on the names of time zones

The Wikipedia article tz database says (excerpts):

The time zones have unique names in the form "Area/Location", e.g. "America/New_York". …

Area is the name of a continent, an ocean, or "Etc". The continents and oceans currently used are Africa, America, Antarctica, Arctic, Asia, Atlantic, Australia, Europe, Indian, and Pacific.

Location is the name of a specific location within the area – usually a city or small island.

Country names are not used in this scheme, primarily because they would not be robust, owing to frequent political and boundary changes. The names of large cities tend to be more permanent. …

So the name US/Eastern is from a time when names were created following other rules.

About the abbreviation, ET

Since I sensed a doubt in a couple of the comments: North American Eastern Time may be and is commonly abbreviated ET. One way to see this is in the Time Zone Abbreviations – Worldwide List. You can also see that ET may either comprise both EST (Eastern Standard Time) and EDT (Eastern Daylight Time) or be used as a synonym for EST, also known as Tiempo del Este in Spanish. When you study the list, you will also see that very many abbreviations are ambiguous.

Or in Java (using REPL):

jshell> ZoneId.of("America/New_York").getDisplayName(TextStyle.SHORT, Locale.US) 
$3 ==> "ET"

Just out of curiosity and not recommended because of the risk of ambiguity: you may also go the other way and obtain the ZoneId from the abbreviation:

jshell> var dtf = DateTimeFormatter.ofPattern("z", Locale.US);
dtf ==> ZoneText(SHORT)

jshell> ZoneId.from(dtf.parse("ET"))
$7 ==> America/New_York

I repeat: don’t try this last trick at home.

Ole V.V.
  • 81,772
  • 15
  • 137
  • 161
  • The word "deprecated" does not appear in the source files. If you want the timezone rules for the entire Eastern timezone of the US, then `US/Eastern` makes the most sense. The same goes for any timezone defined at the national level. Those `US/*` names will not go away, especially if New York, Chicago, Denver, Los Angeles, or any other city decides to use their own rules that differ from the national rules. – lilole Oct 25 '21 at 19:19
  • 1
    @lilole I believe that you are shooting the messenger? The author of the Wikipedia article that I am referencing and linking to did not make that up himself/herself. Even though not explicit in the source files, the folks behind the IANA time-zone database do make the distinction between deprecated and non-deprecated time zone IDs. All the canonical ones are in *region/city* format. I understand your objection, but it is not in my power to re-apprecate(?) US/Eastern or any other deprecated time zone. Further link: [Deprecated time zones.](https://github.com/tzinfo/tzinfo-data/issues/17) – Ole V.V. Oct 25 '21 at 19:41
  • @lilole You may or may not want to see my edit on the names of time zones. – Ole V.V. Oct 25 '21 at 19:54
  • 1
    Thanks for your link @Ole. It led me to https://data.iana.org/time-zones/theory.html#naming, which explains why they like the AREA/LOCATION format with cities -- essentially country names change more often than city names, and they want to reflect where the zone's "main" clock is. This makes sense in the tiny countries around the world. But "deprecated" is still the wrong word. If you want to stick with it, then you must live by this from your link: _The names are only to be read by 'experts' and are not intended for end users to see._ – lilole Oct 26 '21 at 20:15
  • If you try this in Ruby with `tzinfo` gem installed, you can see what I mean -- a user should not see `America/New_York` as a timezone, but something like `Eastern (most areas)`: `require 'tzinfo'; TZInfo::Country.get("US").zone_info.map { [_1.description, _1.identifier] }.sort` – lilole Oct 26 '21 at 20:33
  • 1
    Thanks, @lilole, for your comments. I can live happily with that. All I want is to reference my sources correctly and loyally. I’d by curious to see what your answer to the question will look like if you post one. In tiny countries, yes, and occasionally in large ones such as the (now former) Soviet Union. – Ole V.V. Oct 26 '21 at 21:40
  • 1
    Cheers @Ole. Your comments made me think harder. For this particular question, between `US/Eastern` and `America/New_York`, neither is incorrect. In code I always vote for what is closest to the original meaning. And it's really ok to disagree with Wikipedia sometimes! – lilole Oct 28 '21 at 22:24
0

If you do:

System.out.println(TimeZone.getTimeZone(("US/Eastern")));
System.out.println(TimeZone.getTimeZone(("America/New_York")));

The output is:

sun.util.calendar.ZoneInfo[id="US/Eastern",offset=-18000000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=US/Eastern,offset=-18000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]


sun.util.calendar.ZoneInfo[id="America/New_York",offset=-18000000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=America/New_York,offset=-18000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]

Which shows every value that is set is exactly the same. There is no difference between the two.

However, thanks to Andreas's comment, it would be optimal to use America/New_York instead of US/Eastern as it is deprecated, shown here and official list here.

According to the official list on the github by the author of the database, US/Eastern exists solely for backwards compatibility.

Nexevis
  • 4,647
  • 3
  • 13
  • 22
  • ...at the moment... ;-) – T.J. Crowder Jun 25 '19 at 17:23
  • I think it is pretty ridiculous to suggest New York might change its TimeZone when it isn't even near the edge of the TimeZone [border](https://en.wikipedia.org/wiki/Eastern_Time_Zone#/media/File:Timezoneswest.PNG). And either way they are currently linked, so in the event that DOES happen, the Database would need to change anyway. – Nexevis Jun 25 '19 at 17:26
  • The database, yes; the code, no, provided the OP uses the correct timezone identifier for what they *really* want. (And as I've said elsewhere: It seems **really** unlikely NY would change timezone.) – T.J. Crowder Jun 25 '19 at 17:28
  • 6
    According to [Wikipedia](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones), `US/Eastern` is listed as *Deprecated*, and **`America/New_York`** is listed as *Canonical*. – Andreas Jun 25 '19 at 17:30
  • 3
    "Which shows every value that is set is exactly the same." Of course, an easier way to show this would be using [`TimeZone.hasSameRules`](https://docs.oracle.com/javase/7/docs/api/java/util/TimeZone.html#hasSameRules(java.util.TimeZone)). – Andy Turner Jun 25 '19 at 19:22
  • Nowhere does the word "deprecated" appear in the source files. The `US/*` names simply cannot go away, as long as there is a national standard for timezones across the entire country. Just like in any other code you write, use the name that matches what you actually mean. – lilole Oct 25 '21 at 19:09