CODEWITHSUNDEEP
javadatetimetimezonejodatime
Milan Kamboya
Milan Kamboya

Reputation: 506

Will Offset value handle Daylight Saving Timezone in Java?

TimeZone.setDefault(TimeZone.getTimeZone("GMT-7:00"));

Will this handle daylight saving timezone?

or

Need region name only like : 'America/Lost_Angeles'?

Upvotes: 1

Views: 1303

Answers (3)

Ashok
Ashok

Reputation: 41

For daily light saving timezone time will be advanced for one hour from November to March in warmer months. You need to check timezone is applicable for day light saving and whether the given date falls in between these duration.

Java provide methods for both of them

TimeZone tz = TimeZone.getTimeZone("GMT5:00");
if(tz.useDaylightTime() && tz.inDaylightTime(date1)) {
                    dst =TimeZone.getTimeZone(userTzStr).getDSTSavings();
}

The value will be in milliseconds and equivalent to one hour and can be added into hour before returning the date in given format.

Upvotes: 1

Anonymous
Anonymous

Reputation: 86324

As you may be aware, Los Angeles is at offset −08:00 during the standard time of the year and at offset −07:00 during summer time (DST) (like now). Other time zones use offset -07:00 some of the year or all of it. America/Phoenix uses -07:00 all year. America/Denver uses -07:00 during standard time and -06:00 during summer.

Java is no thought reader so would have no chance to guess that by -07:00 you might mean one of these time zones or one of the many other time zones that also use -07:00. So when you ask for -07:00, you get -07:00 all year.

Will this handle daylight saving timezone?

No.

or

Need region name only like : 'America/Los(t)_Angeles'?

Yes.

I recommend you don’t use the TimeZone class. It is poorly designed and long outdated. Instead use ZoneId from java.time, the modern Java date and time API. Or if you’re already using Joda-Time, then its DateTimeZone is an option too, but the Joda-Time project is in maintenance mode and not recommended for new code.

And in particular don’t use TimeZone.setDefault(). This will affect every part of your program and all other programs running in the same JVM. The best solution is to make time zone explicit in all your date-time operations so that you are independent of any default time zone setting. If for some reason you can’t do that (maybe can’t afford that change to your code base just now), set the default time zone from the command line when starting your program. For example:

java -Duser.timezone=America/Los_Angeles YourJavaMainClass

Link: List of tz database time zones including 36 time zones that use offset -07:00 some or all of the year.

Upvotes: 5

Basil Bourque
Basil Bourque

Reputation: 339043

The Answer by Ole V.V. is correct.

In addition, use caution here. Be aware that setting the default time zone immediately affects all code in all threads of all apps running within that JVM. Use TimeZone.setDefault only as a desperate last resort.

Do not rely upon the default time zone. That leaves the results of your app at the mercy of sysadmins and other Java programmers. Your results at runtime may vary.

Instead, always specify your desired/expected time zone. Pass a ZoneId object as the optional argument to various date-time methods. If omitted, Java implicitly falls back to using the JVM’s current default time zone. Better to specify explicitly the time zone. In my opinion, making the time zone argument optional is one of the very few design faults in the otherwise superb java.time classes, as too many programmers are unaware of the crucial role played by time zone. 

ZoneId z = ZoneId.of( "America/Montreal" ) ;
ZonedDateTime zdt = ZonedDateTime.now( z ) ;

"GMT-7:00"

If you must use an offset-from-UTC, use a smart object, not a dumb string. The appropriate class is ZoneOffset.

ZoneOffset offset = ZoneOffset.of( -7 ) ;

But always use a time zone in preference to a mere offset. An offset is a number of hours-minutes-seconds ahead or behind the UTC baseline.

A time zone, in contrast, is much more. A time zone is a history of the past, present, and future changes to the offset used by the people of a region.

The offset for any region changes surprisingly often. For one thing, politicians in many places have fallen for the foolishness of Daylight Saving Time (DST). For decades those politicians have been busy adopting DST, changing the start and stop dates of DST, going off DST, rejoining DST. Now, the current fad is deciding to stay permanently on DST. Round and round the carousel goes. But politicians change offsets for other reasons too, such as to unify their country like India, or to make a statement by matching or differing the time zones of their neighbors as did North Korea recently.

So avoid relying on a fixed offset. Use a time zone wherever known with certainty.

And keep up-to-date the “tzdata" time zone database copies found in:

  • Your JVM.
  • Your operating system such as BSD/macOS/Linux/Windows/Solaris/AIX.
  • Your database engines such as Postgres.
  • Your software libraries doing date-time functions.

Upvotes: 3

Related Questions