5

I've an application that depends heavily on Java. We do extensive logging, database insertion, etc. After the day light timing switch we noticed that all Java time is about an hour behind. We've Jre version of 1.6_18. I thought this issue was resolved in earlier versions of Java. Do suggest as to what can be done, if there are any patches for this.

user737159
  • 71
  • 1
  • 3
  • 2
    Can you post the part of the code that is getting you the unexpected result? Just a guess at this point, but it could be that your default date/time is set for the wrong time zone, or for one that doesn't recognize daylight saving, or some other little thing. – jefflunt May 04 '11 at 01:35
  • 2
    What locale is your application using? – Synesso May 04 '11 at 01:35
  • 1
    @Synesso - yeah, that's what I meant to say. :) – jefflunt May 04 '11 at 01:53
  • 2
    Oops, and I meant to say timezone, not locale. ;) – Synesso May 05 '11 at 00:30
  • Best to do your logging and tracking in [UTC](https://en.wikipedia.org/wiki/Coordinated_Universal_Time) rather than any one time zone. Time zones and Daylight Saving Time (DST) are frequently revised. Also, any code in any thread of any app within the JVM can change the current default time zone. Call `Instant.now()` to get the current moment in UTC. – Basil Bourque Jul 15 '16 at 22:21

2 Answers2

5

Timezone information is modified periodically. Java 6 update 18 is likely to have out of date DST settings for your location.

Either upgrade to the latest (update 25) or run the TZupdater tool.

EDIT: I have just discovered that Oracle provides an RSS feed for timezone updates. If your application absolutely must have the most recent TZ data keep an eye on this.

Synesso
  • 37,610
  • 35
  • 136
  • 207
  • Well this is for machines in the Eastern Standard time, how often is the settings changed? – user737159 May 04 '11 at 20:49
  • Java 6 update 18 has Olsen TZ data 2009s. Java 6 update 25 has Olsen TZ data 2011b. The differences are shown on this page: http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html I don't see anything specifically for your timezone in that diff, but try it out, it may help. – Synesso May 04 '11 at 21:30
  • Another thing to consider: You might reasonably assume your application is running in a particular timezone, but your assumption might be wrong. Introspect that beast at runtime `java.util.TimeZone.getDefault().getID()` to be absolutely certain. – Synesso May 05 '11 at 00:29
  • The thing is that this machine has multiple versions of java running as they've other applications on it. Even though our application is specifically tied to the update 18, I wonder if the other versions can screw up Java time for our application – user737159 May 24 '11 at 18:54
  • 1
    According to the Timezone Updater Tool page "A single image of the JDK/JRE software is modified per execution." (http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html) There are instructions on how to apply tz updates across multiple JREs on the same system. (Personally I'd do them one at a time to be safe). – Synesso May 24 '11 at 23:40
  • We stopped the services and applied the timezone updater on every instance of Java, but restarted the services and the java time was still one hour behind. We're trying next to check if the timezone it say its in is valid. It should be in Eastern Central time, wonder somehow it thinks its in Central time. – user737159 May 25 '11 at 14:10
  • Well the eventual solution is crazy to say the least. We stopped all the services. Went to the date and time window,uncheked the option for automatically adjust daylight savings and rechecked it again and now Java went back to the original timing..wow..talk about software..thanks for all the help – user737159 Jun 17 '11 at 14:06
  • Ouch, glad you got it sorted. – Synesso Jun 20 '11 at 21:32
  • 1
    @user737159 This is one reason why it is usually best to keep your servers on UTC time zone (or set for Reykjavík Iceland if no UTC). Keep your business logic and data storage in UTC. Adjust to a non-UTC time zone only for presentation where expected by the user. – Basil Bourque May 19 '15 at 00:01
2

tl;dr

Use UTC

Think of UTC as the “one true time”. Any date-time for a particular time zone is a derivation of UTC. When at work doing programming or sys-admin work, forget about your own local time zone. I strongly suggest adding a clock to both your physical and digital desktops displaying UTC. In a pinch, use a web site such as Time.is.

Most of your business logic, logging, data storage, data exchange, and database persistence should all be in UTC. Adjust into a time zone only for presentation.

Avoid old date-time classes

Avoid the troublesome old legacy date-time classes bundled with the earliest versions of Java. Now supplanted by the java.time classes.

Instant

The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds.

Instant now = Instant.now(); // Current moment in UTC.

Specify time zone

The Java Virtual Machine has a current default time zone. This may be picked up at launch from the host OS. Or it may be set at launch by configuration settings. Or it may be changed at any moment by any code in any thread of any app within the JVM -- affecting all other code during execution!

Given that the JVM’s current default time zone varies, and is outside your control as a programmer, never depend on it. Always specify your desired/expected time zone.

Generally best to keep server host OS set to a time zone of UTC, but again, never depend on that in your programming.

ZonedDateTime

To adjust an Instant into a time zone, generate a ZonedDateTime object.

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

Call toString to generate a String in standard ISO 8601 format. For other formats, search Stack Overflow for the class DateTimeFormatter.

Update your tz time zone database

Time zone definitions and their anomalies such as Daylight Saving Time (DST) change frequently, surprisingly often.

Oracle release regular updates of Java that include fresh copies of the tz database. If you cannot install those Java updates, or if a nearly last-minute change to zones was made by some careless politicians, you can manually update your Java using the Timezone Updater Tool by Oracle.

Locale

Know that Locale has nothing to do with time zone. A Locale defines (a) a human language to use for translation, and (b) cultural norms deciding issues such as abbreviation, punctuation, and order of parts. So you only need a Locale when generating Strings, when using the DateTimeFormatter class.

Locale l = Locale.CANADA_FRENCH;
DateTimeFormatter f = DateTimeFormatter.ofLocalizedDateTime( FormatStyle.FULL ).withLocale( l );
String output = zdt.format( f );

So a time zone defines the meaning of a date-time value, but a Locale defines its presentation.

About java.time

The java.time framework is built into Java 8 and later. These classes supplant the troublesome old date-time classes such as java.util.Date, .Calendar, & java.text.SimpleDateFormat.

The Joda-Time project, now in maintenance mode, advises migration to java.time.

To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations.

Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport and further adapted to Android in ThreeTenABP (see How to use…).

The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.

Community
  • 1
  • 1
Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154