Why the timezone vary from main method and form web application in java

Question

I am getting the system current timezone:

Calendar calendar = new GregorianCalendar();
TimeZone systemTimeZone = calendar.getTimeZone(); 

1. If I run from the Java main method, it gives the correct system timezone.
2. If I run from the web application (from REST web services) it gives Asia/Irkutsk as a timezone.

But it is wrong, why?

Answer 1

tl;dr

• Use java.time classes.
• Specify your desired/expected time zone explicitly.

Example:

ZonedDateTime                     // Represents a moment as seen through the wall-clock time used by the people of a particular region.
.now(                             // Capture the current moment as seen in this time zone.
    ZoneId.of( "Asia/Kolkata" )   // Real time zone names are in `Continent/Region` format. Never use 2-4 letter pseudo-zones such as `IST`, `EST`, or `CST`. 
)

Generally best to use UTC for most of your work.

Instant.now()  // Capture current moment in UTC.

Details

The JVM keeps a default time zone. This default is implicitly applied unless you specify one.

When you run your Java app locally, the current default time zone of your local JVM is implicitly applied.

When you run a Java web app, the current default time zone of the Servlet container's JVM is implicitly applied.

I suggest you stop using the terrible date-time classes such as Calendar. These are now legacy, supplanted years ago by the modern java.time classes defined in JSR 310.

I strongly suggest always specifying your desired/expected time zone. The default zone is outside your control as a programmer. Either the sysadmin or any other code in any app within the JVM can change the default time zone while your app is running.

To capture the current moment in UTC, use Instant.

Instant instant = Instant.now() ;  // Capture current moment in UTC.

To capture the current moment as seen in a particular time zone, use ZonedDateTime.

ZoneId z = ZoneId.of( "Africa/Tunis" ) ;
ZonedDateTime zdt = ZonedDateTime.now( z ) ;

---

About java.time

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

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

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

You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.

Where to obtain the java.time classes?

• Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
  • Java 9 adds some minor features and fixes.
• Java SE 6 and Java SE 7
  • Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
• Android
  • Later versions of Android bundle implementations of the java.time classes.
  • For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….

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.