Converting the "America/Los Angeles" time zone to "PST" or "PDT" in Java ME

Question

My server sends me time zones of the format "America/Los Angeles". On the client, I have a time that I need to display in that time zone. The answer will be "PST" or "PDT", depending on daylight savings at the given time. How do I do that conversion?

I'm on Java ME (Blackberry 4.7, to be accurate), so I can't use Joda Time.

I will need to make this calculation rapidly for a lot of dates (but only one time zone), so I can't just have the server send me an offset, because the offset might change depending on the date.

Edit: Let me restate the problem, because there seems to be some confusion. I am given a zoneinfo name and a date. I want to know the offset from GMT in that timezone at that date. The answer will vary depending on daylight savings time.

As an added bonus, I'd like to get the TLA to show to the user (i.e., "PST" or "PDT"), but that's secondary.

Solution: I'll summarize the solution here, because it isn't terribly clear from the answers below. This essentially does what I need, in J2ME:

TimeZone zone = TimeZone.getTimeZone("America/Los_Angeles");
Calendar calendar = Calendar.getInstance();
calendar.setTimeZone(zone);

calendar.setTime(new Date(2011, 1, 1, 12, 0, 0));      
System.out.println(zone.getOffset(1, calendar.get(Calendar.YEAR), calendar.get(Calendar.MONTH), calendar.get(Calendar.DAY_OF_MONTH), calendar.get(Calendar.DAY_OF_WEEK), calendar.get(Calendar.MILLISECOND)));
calendar.setTime(new Date(2011, 6, 1, 12, 0, 0));
System.out.println(zone.getOffset(1, calendar.get(Calendar.YEAR), calendar.get(Calendar.MONTH), calendar.get(Calendar.DAY_OF_MONTH), calendar.get(Calendar.DAY_OF_WEEK), calendar.get(Calendar.MILLISECOND)));

Gossett

Due to this answer, 'Amrica/Los_angeles' and 'PDT' have equal offset! – Pestilent

Answer 1

May be this is what you are wanting. This works on my machine using standard java.

        Calendar calendar = Calendar.getInstance();       
        TimeZone tz = TimeZone.getTimeZone("America/Los_Angeles");
        calendar.setTimeZone(tz);
         System.out.println("Offset from UTC="+tz.getOffset(calendar.getTimeInMillis())/(60*60*1000)); //prints -8
        System.out.println(tz.getDisplayName(Boolean.TRUE, 0)); //prints PDT
        System.out.println(tz.getDisplayName(Boolean.TRUE, 1)); //prints Pacific Daylight Time
        System.out.println(tz.getDisplayName(Boolean.FALSE, 0));//prints PST
        System.out.println(tz.getDisplayName(Boolean.FALSE, 1));//prints Pacific Standard Time  

Update: OP said the above does not work for j2ME. After googling I found here that getOffset() is actually getRawOffset() in j2me. However, it does not look like it supposrts displayName. Your only option I think is to go through the ids using getAvailableIds().

Inverse

That would be great, but J2ME doesn't have TimeZone.getDisplayName() :-( – Gossett

I added the offset for you as well. – Inverse

Does it support the getOffset()? – Inverse

My previous comment was dumb, so I deleted it. getRawOffset() can't work, because it doesn't take a date. J2ME has only the long form getOffset(), which I got to work with the code I added above. – Gossett

Answer 2

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

Solution using java.time, the modern Date-Time API:

You can create an instance of ZonedDateTime which has been designed to adjust the timezone offset automatically on DST transitions.

If you need timezone offset but not the timezone name, you can convert a ZonedDateTime into OffsetDateTime using ZonedDateTime#toOffsetDateTime.

Demo:

import java.time.LocalDate;
import java.time.LocalDateTime;
import java.time.LocalTime;
import java.time.OffsetDateTime;
import java.time.ZoneId;
import java.time.ZonedDateTime;

public class Main {
    public static void main(String[] args) {
        ZoneId zoneIdLosAngeles = ZoneId.of("America/Los_Angeles");
        ZonedDateTime zdtNowLosAngeles = ZonedDateTime.now(zoneIdLosAngeles);
        System.out.println(zdtNowLosAngeles);

        // With zone offset but without time zone name
        OffsetDateTime odtNowLosAngeles = zdtNowLosAngeles.toOffsetDateTime();
        System.out.println(odtNowLosAngeles);

        // ################ A winter date-time ################
        ZonedDateTime zdtLosAngelesWinter = ZonedDateTime
                .of(LocalDateTime.of(LocalDate.of(2021, 11, 20), LocalTime.of(10, 20)), zoneIdLosAngeles);
        System.out.println(zdtLosAngelesWinter); // 2021-11-20T10:20-08:00[America/Los_Angeles]
        System.out.println(zdtLosAngelesWinter.toOffsetDateTime()); // 2021-11-20T10:20-08:00
    }
}

Output from a sample run:

2021-07-18T04:09:57.993440-07:00[America/Los_Angeles]
2021-07-18T04:09:57.993440-07:00
2021-11-20T10:20-08:00[America/Los_Angeles]
2021-11-20T10:20-08:00

ONLINE DEMO

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

---

^{* 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.}

Dearborn

Answer 3

Does J2ME not support TimeZone.getTimeZone(id)? That's basically what you want, in order to get the time zone offsets etc. I'd hope that J2ME supports zoneinfo zone names.

Jori

That gives me the timezone with the id "America/Los Angeles", which is exactly equal to PST, regardless of the date. – Gossett

BlackBerry's TimeZone implementation supports zoneinfo names. The problem OP has, I think, is that he's receiving timezone abbreviations, not zoneinfo names. BlackBerry defaults to GMT if it can't recognize the abbreviation. Unfortunately, BB models often don't know many abbreviations. You can use TimeZone.getAvailableIDs() to see what's supported on a particular platform. – Tahr

@Ted: the question says the OP is getting the zoneinfo name. I'm still somewhat confused... – Jori

@Marvin: How have you determined that "America/Los Angeles" is exactly equal to PST? That would surprise me. – Jori

You're right, they are different. I was wrong. Thanks for pointing that out! – Gossett