20

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");
14
  • 1
    Did you read the javadoc for ZoneId? It explains where these names come from and their precedence. Jun 25, 2019 at 16:57
  • 3
    @JClassic Not a good idea..if I use that, I have to change 1 times a year..
    – nimo23
    Jun 25, 2019 at 17:03
  • 5
    @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. Jun 25, 2019 at 17:03
  • 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. Jun 25, 2019 at 17:04
  • 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. Jun 25, 2019 at 18:03

3 Answers 3

20

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...

1
  • 5
    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. Jun 26, 2019 at 15:56
9

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.

7
  • 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, 2021 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.
    – Anonymous
    Oct 25, 2021 at 19:41
  • 1
    Thanks for your link @Ole. It led me to 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, 2021 at 20:15
  • 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.
    – Anonymous
    Oct 26, 2021 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, 2021 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.

6
  • ...at the moment... ;-) Jun 25, 2019 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. And either way they are currently linked, so in the event that DOES happen, the Database would need to change anyway.
    – Nexevis
    Jun 25, 2019 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.) Jun 25, 2019 at 17:28
  • 6
    According to Wikipedia, US/Eastern is listed as Deprecated, and America/New_York is listed as Canonical.
    – Andreas
    Jun 25, 2019 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. Jun 25, 2019 at 19:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.