The correct Answer by Anoop LL should be accepted. JSP pages are indeed compiled on the server-side, and their Java code is executed on the server-side. I'll add a bit more info.
Date is UTC
The java.util.Date is in UTC. Its toString method confusingly applies the JVM’s current default time zone while generating the string. This creates the illusion of a time zone in the Date.
Avoid legacy date-time classes
You should avoid the troublesome old class, java.util.Date, now legacy, supplanted by the java.time classes.
Using java.time
To capture the current moment in UTC, use the Instant class.
Instant instant = Instant.now();
To view this moment through the lens of some region’s wall-clock time, apply a time zone, a ZoneId, to get a ZonedDateTime.
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter abbreviation such as EST or GMT or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "America/Montreal" );
ZonedDateTime zdt = instant.atZone( z );
As a shortcut, go directly to ZonedDateTime by calling its now method and passing the desired time zone.
ZonedDateTime zdt = ZonedDateTime.now( z );
Never rely on the JVM’s current default time zone. It may change at any time with any call from any code in any thread of any app within the JVM. Instead, specify your desired/expected time zone explicitly by passing any option time zone argument.
You can further adjust into other time zones.
ZonedDateDate zdtLosAngeles = instant.atZone( ZoneId.of( "America/Los_Angeles" ) );
ZonedDateDate zdtParis = instant.atZone( ZoneId.of( "Europe/Paris" ) );
ZonedDateDate zdtKolkata = instant.atZone( ZoneId.of( "Asia/Kolkata" ) );
ZonedDateDate zdtAuckland = instant.atZone( ZoneId.of( "Pacific/Auckland" ) );
All four of the ZonedDateTime objects in the code above represent the very same moment, the very same point on the timeline. They each carry a different wall-clock time, as if four people on a world-wide conference call each simultaneously looked up at a clock on their wall.
Work in UTC
When in doubt, work in UTC. Most of your business logic, data storage, and data exchange should be in UTC. Stop thinking about your own local time zone. Think of UTC as the “One True Time”. All other zoned times are mere variation on that UTC theme.
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.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
Where to obtain the java.time classes?
- Java SE 8 and SE 9 and later
- Built-in.
- Part of the standard Java API with a bundled implementation.
- Java 9 adds some minor features and fixes.
- Java SE 6 and SE 7
- Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
- Android
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.
