CODEWITHSUNDEEP
javatimezone
MonoThreaded
MonoThreaded

Reputation: 12033

Java TimeZone head scratching

I would like to save some user timezone in a Daylight saving proof format.
My goal is to get the correct GMT offset whenever the code gets executed.
In order to figure out my best option, I wrote the following:

ArrayList<String> list = new ArrayList<String>();
list.add( "EST");
list.add( "EDT");
list.add( "America/New_York");
long now = System.currentTimeMillis();
for( String tzID: list) {
    TimeZone tz = TimeZone.getTimeZone( tzID);
    System.out.println( tzID + " now=" + tz.getOffset( now) / 3600000 + " / +182=" + tz.getOffset( now + ( 182 * 86400000)) / 3600000);
}

For short, give me the offset now and in 182 days
Executed September 3rd, the output is

EST now=-5 / +182=-5
EDT now=0 / +182=0
America/New_York now=-4 / +182=-4

This is unexpected for several reasons
1) Why is America/New_York not giving -4/-5 ?, Isn't it supposed to be date sensitive?
2) Why does EDT == UTC?

Upvotes: 1

Views: 464

Answers (3)

Arvind Kumar Avinash
Arvind Kumar Avinash

Reputation: 79075

java.time

The question and the accepted answer use the java.util date-time API which was the right thing to do in 2012. In March 2014, the modern Date-Time API was released as part of the Java 8 standard library which supplanted the legacy date-time API and since then it is strongly recommended to switch to java.time, the modern date-time API.

Solution using java.time

You can use ZonedDateTime which automatically adjusts the time zone offset for a given ZoneId.

Demo:

import java.time.ZoneId;
import java.time.ZonedDateTime;

class Main {
    public static void main(String[] args) {
        ZoneId zone = ZoneId.of("America/New_York");
        ZonedDateTime now = ZonedDateTime.now(zone);
        ZonedDateTime after182Days = now.plusDays(182);
        System.out.println(zone + " now=" + now.getOffset() + " / +182=" + after182Days.getOffset());
    }
}

Output as of now:

America/New_York now=-05:00 / +182=-04:00

ONLINE DEMO

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

Do not use three-letter timezone ID: Note from the Java 7 Timezone documentation:

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.

Upvotes: 5

Peter Lawrey
Peter Lawrey

Reputation: 533510

One problem you have is that 182 * 86400000 overflows. If you use

long now = System.currentTimeMillis();
for( String tzID: "EST,EDT,America/New_York".split(",")) {
    TimeZone tz = TimeZone.getTimeZone( tzID);
    System.out.println( tz.getDisplayName() + " now=" + tz.getOffset( now) / 36e5 
                     + " / +182=" + tz.getOffset( now + 182 * 86400000L) / 36e5);
}

prints

Eastern Standard Time now=-5.0 / +182=-5.0
Greenwich Mean Time now=0.0 / +182=0.0
Eastern Standard Time now=-4.0 / +182=-5.0

If you look at the javadoc and source for getTimeZone you can see

 * @return the specified <code>TimeZone</code>, or the GMT zone if the given ID
 * cannot be understood.

public static synchronized TimeZone getTimeZone(String ID) {
return getTimeZone(ID, true);
}

private static TimeZone getTimeZone(String ID, boolean fallback) {
TimeZone tz = ZoneInfo.getTimeZone(ID);
if (tz == null) {
    tz = parseCustomTimeZone(ID);
    if (tz == null && fallback) {
    tz = new ZoneInfo(GMT_ID, 0);
    }
}
return tz;
}

In short, EDT is not recognised so it becomes GMT.

Upvotes: 3

Jon Skeet
Jon Skeet

Reputation: 1500515

I suspect this is the problem:

now + ( 182 * 86400000)

The parenthesized arithmetic expression overflows 32 bits. You probably want:

now + ( 182 * 86400000L)

However, that still assumes that any daylight saving time will be applied for roughly six months, which is certainly not the case in the real world. For example, looking at the Sao Paolo time zone, it switches in October and February - so if you ran your code in September, you'd end up seeing -3 / -3. Even for time zones where DST switches on/off roughly every six months, you're very likely to find 182 consecutive days each year without a switchover (almost by definition, given that that's slightly less than half a year).

It's not clear exactly what you're trying to do, but I suspect you should really just be saving the time zone ID, e.g. "America/New_York". Almost anything else is asking for trouble.

Upvotes: 3

Related Questions