Difference between EST and America/New_York time zones

Question

Can somebody please tell, what's the difference between the following two statements:

TimeZone.getTimeZone("America/New_York")

and

TimeZone.getTimeZone("EST")

In other words, why is EST different from America/New_York. Also in my application, to get the current time zone in US, should I use America/New_York or EST.

Naturally

Answer 1

EST is half of the New York time zone, effectively. It's always in standard time - it doesn't have the daylight saving part. It's not really a proper time zone in its own right, IMO - it's the "standard" part of a fuller time zone. When writing about a time zone which is just a fixed offset and not related to a particular place, I'd prefer to use "Etc/GMT+5" or something similarly obviously-fixed. (I don't generally like even "Eastern Time" and the like, as different places which observe "Eastern Time" may vary in their DST transitions. It's a bit like calling an encoding "extended ASCII"... it tells you some information, but not quite enough.)

So if you want to know the actual local time for New York at any particular instant, use America/New_York.

In general, stay away from the abbreviations. From the documentation:

For compatibility with JDK 1.1.x, some other three-letter time zone IDs (such as "PST", "CTT", "AST") are also supported. However, their use is deprecated because the same abbreviation is often used for multiple time zones (for example, "CST" could be U.S. "Central Standard Time" and "China Standard Time"), and the Java platform can then only recognize one of them.

(Personally I'd also advise you to stay away from Date and Calendar, preferring to use Joda Time wherever possible. That's a different matter though, really.)

Primal

I think suggesting it's not a proper time zone is misleading, since some timezones don't have DST/non-DST splits. Do names like EST get used for nautical timezones, or do they just use offsets? – Merrymaking

@JamesAylett: Pass. I'd really hope not, given that they're ambiguous. (IIRC, CST is ambiguous between "Central Standard Time" and "Central Summer Time in Australia, which is particularly unhelpful - although one of those hasn't been used for many years.) Nice to see you, btw :) – Primal

@JamesAylett: I was suggesting that it's not a proper time zone not because it doesn't observe DST, but because it's clearly part of something which does observe DST - otherwise the "Standard" part would be redundant. Of course "GMT" becomes tricky around 1969 too, when it deviated from the not-yet-in-existence UTC :( – Primal

Yes, I know why and to that extent I entirely agree; but the existence of parts of the world where DST isn't observed feels like something worth pointing out. Of course, when you get historical, time zones are increasingly painful, DST very painful, DDST…well, doubly so. – Merrymaking

I think the only way to make any sense of the mess that is date/time arithmetic is to enforce strict conventions. The distinction that "New York Time" is sometimes "EDT" and sometimes "EST" means that you have to stick to the New York time zone to be unambiguous. – Tazza

You can use the new Java8 date API: java.time.LocalDate java.time.LocalTime java.time.LocalDateTime java.time.ZonedDateTime – Nickelodeon

Perfect answer; exactly what I was looking for. – Strove

Answer 2

EST is UTC - 5 hours. America/New_York is EST in the winter and E*D*T in the summer, so right now New York is UTC - 4 hours.

Josi

Answer 3

The timezone, America/New_York observes two different timezone offsets:

1. EST (winter time): has a timezone offset of -05:00 hours
2. EDT (summer time): has a timezone offset of -04:00 hours

java.time

The java.util Date-Time API and their formatting API, SimpleDateFormat are outdated and error-prone. It is recommended to stop using them completely and switch to the modern Date-Time API^*.

Also, quoted below is a notice from the home page of Joda-Time:

Note that from Java SE 8 onwards, users are asked to migrate to java.time (JSR-310) - a core part of the JDK which replaces this project.

What Date-Time object should I use to adjust the offset automatically?

Use ZonedDateTime which has been designed to adjust the timezone offset automatically.

Demo:

import java.time.LocalDate;
import java.time.LocalTime;
import java.time.Month;
import java.time.ZoneId;
import java.time.ZonedDateTime;

public class Main {
    public static void main(String[] args) {
        ZoneId zoneId = ZoneId.of("America/New_York");

        // Custom times
        ZonedDateTime zdtDstOn = ZonedDateTime.of(LocalDate.of(2020, Month.OCTOBER, 22), LocalTime.MIN, zoneId);
        ZonedDateTime zdtDstOff = ZonedDateTime.of(LocalDate.of(2020, Month.NOVEMBER, 22), LocalTime.MIN, zoneId);
        System.out.println(zdtDstOn);
        System.out.println(zdtDstOff);

        // Current time
        ZonedDateTime zdtNow = ZonedDateTime.now(zoneId);
        System.out.println(zdtNow);
    }
}

Output:

2020-10-22T00:00-04:00[America/New_York]
2020-11-22T00:00-05:00[America/New_York]
2021-08-17T12:19:41.854781-04:00[America/New_York]

ONLINE DEMO

Avoid using the abbreviated timezone names

The following quote from the documentation states the problem clearly:

Three-letter time zone IDs

For compatibility with JDK 1.1.x, some other three-letter time zone IDs (such as "PST", "CTT", "AST") are also supported. However, their use is deprecated because the same abbreviation is often used for multiple time zones (for example, "CST" could be U.S. "Central Standard Time" and "China Standard Time"), and the Java platform can then only recognize one of them.

Then, what Date-Time object should I use for a fixed timezone offset?

Use OffsetDateTime for a fixed timezone offset.

Demo:

import java.time.LocalDate;
import java.time.LocalTime;
import java.time.Month;
import java.time.OffsetDateTime;
import java.time.ZoneOffset;

public class Main {
    public static void main(String[] args) {
        ZoneOffset zoneOffset = ZoneOffset.of("-04:00");

        // A custom time
        OffsetDateTime odt = OffsetDateTime.of(LocalDate.of(2020, Month.OCTOBER, 22), LocalTime.MIN, zoneOffset);
        System.out.println(odt);

        // Current time
        OffsetDateTime odtNow = OffsetDateTime.now(zoneOffset);
        System.out.println(odtNow);
    }
}

Output:

2020-10-22T00:00-04:00
2021-08-17T12:36:09.123599-04:00

ONLINE DEMO

Note: For any reason, if you need to convert an object of OffsetDateTime or ZonedDateTime to an object of java.util.Date, you can do so as follows:

Date date = Date.from(odtNow.toInstant());

or

Date date = Date.from(zdtNow.toInstant());

Learn more about the modern Date-Time API^* from Trail: Date Time.

Check this answer and this answer to learn how to use java.time API with JDBC.

---

^{* For any reason, if you have to stick to Java 6 or Java 7, you can use ThreeTen-Backport which backports most of the java.time functionality to Java 6 & 7. If you are working for an Android project and your Android API level is still not compliant with Java-8, check Java 8+ APIs available through desugaring and How to use ThreeTenABP in Android Project.}

Lectureship