Building TimeZone object in Java

I build a Java TimeZone object using the TimeZone String like GMT-8,GMT,PST,EST etc. This did not consider whether the timezone is daylight saving enabled or not.Now there is a requirement to include this check and instead of giving the input as PDT or EDT the daylight saving is given as a seperate flag.I am not sure whether TimeZone has a direct method to change the dayLight saving property of that TimeZone.

So if I get an input like PST and DaylightSaving as true then I have to change the string as PDT.Whats even worse is sometimes I will get inputs like GMT-8 or GMT-6 with Day light flag as either true or false. Is there a way out ?

I can't use thirdparty TimeZone related classes

Code Sample:

TimeZone  timeZone = TimeZone.getTimeZone("EST");
TimeZone  ti开发者_如何转开发meZone = TimeZone.getTimeZone("PST");
TimeZone  timeZone = TimeZone.getTimeZone("GMT-8");

---

Timezone strings like "PST" and "GMT-8" are often ambiguous, and often do not tell you whether daylight savings rules are in force. (For instance, "PST" means both "Pacific Standard Time" and "Pakistan Standard Time".)

If you want to get the timezones and daylight saving rules correct, you have to use full timezone names to obtain the TimeZone object; i.e. names of the form: "America/Los_Angeles".

Alternatively use ISO 8601 date / time values.

Have to change lots of codes and its little difficult to convince others to get approvals.

Well, I'd say you've got little choice here ... if you want your code to get the timezones, etc correct.

Do some research, understand the problems, explain the problem your boss / client, and let them choose between an application that cannot get daylight savings time right, and one that uses a more sensible date format and timezone specification method.

---

The only other thing I would add is that use of 3 letter timezone id's is deprecated as shown below from JavaDoc. You need to use the names as shown here

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.

---

I think Java is supposed to figure out by itself, whether the time zone is using daylight savings or not, and when this is active.

So if you try to format a certain Date object with that timezone, the output should reflect the daylight savings.

Whether that works reliably (given the frequent changes in this area), I do not know. You should probably update to the latest JVM to get the newest timezone database files (if you cannot do that, there is a separate Time Zone Update tool available).

---

You're not really "building" a TimeZone with the example code you show. You're fetching one that's configured in the Java platform already.

And those built-in TimeZone objects already have the appropriate info about whether daylight saving time is used, when it starts, etc. All those are attributes of the timezone you're fetching.

As mentioned in another comment, those attributes of the built-in TimeZone objects change from time to time. Updates to the Java runtime pick up those changes.

If you did want to really build a new TimeZone instance, there's the subclass SimpleTimeZone that seems to have useful constructors. But is it truly the case that you can't use built-in TimeZones? Seems like you're taking on a bigger job than necessary. TimeZone.getAvailableIDs() will give you the list of TimeZone names in your Java runtime.