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.

---

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.

---

tl;dr

• Your database of time zone ‘tz’ info is likely out-of-date.
• Use the back-port of java.time classes.
  • See Tutorial.
  • Includes up-to-date ‘tz’ database.
  • Avoid troublesome old legacy date-time classes from earliest Java.
• Use UTC for most of your work.

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.