Do i need to change the date along with the timezone

Question

I have a Calendar object [ localDate ] which is in EST : say Nov 6, 15:34... and i set the timeZone to GMT+5:30... Now when i do the Calendar.HOUR_OF_DAY it returns me 2... which i know is perfect.. since its 15:34 + 5 hrs to GMT and then +5:30 to the timezone.. which just means.. 26:04 which is 2 of 7th .

However , the date still stays as Nov 6... and localDate.getTime() still returns Nov 6.. and even when i print the localDate.. it shows the timezone as +5:30 , but the day and everything else is still as the original local Time..[ i.e Nov 6 ]

I am simply unable to understand why so...

Edit ::

So i understand that i do not need to change the date along with the timezone.. Only change the way date is displayed suited to that location and that can be done using the timezone that has been set.

Answer 1

localDate.getTime() returns a java.util.Date which is a quantity of raw time since a fixed point. Timezones only affect the human readable representation of the point in time.

15:34 Nov 6th UTC - 5 and 02:04 Nov 7th UTC + 5:30

are both the exact same point in absolute time. It's just two different human ways of describing the same instant.

So changing the timezone on the calendar has no effect on the value returned by getTime()

Answer 2

Date objects do not have a timezone - a Date object represents an "absolute" moment in time. When you print a Date object (by implicitly or explicitly calling toString() on it):

Date date = ...;
System.out.println(date);

then it will be formatted using some default format that will show the date in your local timezone - no matter if you got the Date object from a Calendar which was set to a different timezone.

If you want to display the Date in a different timezone, use a DateFormat object and set the timezone that you want to display your date in on that object:

Date date = ...;

DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss Z");
df.setTimeZone(TimeZone.getTimeZone("UTC"));  // For example, UTC

// Prints 'date' in UTC
System.out.println(df.format(date));

Answer 3

Question Is Not Clear

Your question is confusing.

You may be confused about the meaning of time zones. As the correct answers by Jesper and Affe said, shifting time zones does not change the point on the time line of the Universe. Suppose Bob in New York US calls Susan in Reykjavík Iceland. Iceland uses UTC as their time zone all year round. Bob and Susan are speaking to each other at the same moment in time. But if Bob looks at the clock on his wall, he sees a time displayed that is 5 hours earlier than a clock on Susan’s wall. New York has a five hour offset behind UTC (-5:00).

Another problem with your question: You also talk about a 5:00 time zone offset as well as a 5:30 offset. Which is it? Or do you have two time zones in mind as well as GMT/UTC?

Joda-Time

I'll take a stab at giving you a bit of example source code.

The Joda-Time library makes date-time work easier.

// © 2013 Basil Bourque. This source code may be used freely forever by anyone taking full responsibility for doing so.

// Use time zone names rather than explicit number of hours offset is generally a good thing.
// Affords Joda-Time an opportunity to make adjustments such as Daylight Saving Time (DST).

// Question asked:
// (1) Start with a US east coast time (Standard offset of -5:00) of November 6, 2013 15:34.
// (2) Move that datetime to UTC (GMT) time zone (no offset).
// (3) Move that datetime to Kolkata (formerly known as Calcutta) India time zone (Standard offset of +05:30).

// Joda-Time has deprecated use of 3-letter time zone codes because of their inconsistency. Use other identifier for zone.
// Time Zone list: http://joda-time.sourceforge.net/timezones.html  (Possibly out-dated, read note on that page)
org.joda.time.DateTimeZone newyorkTimeZone = org.joda.time.DateTimeZone.forID( "America/New_York" );
org.joda.time.DateTimeZone kolkataTimeZone = org.joda.time.DateTimeZone.forID( "Asia/Kolkata" );

// Question calls for: EST Nov 6, 15:34 (Standard offset of -5:00).
// This DateTime constructor calls for passing: year, month, day, time zone.
org.joda.time.DateTime dateTimeInNewYork = new org.joda.time.DateTime( 2013, org.joda.time.DateTimeConstants.NOVEMBER, 6, 15, 34, newyorkTimeZone );
// Move to UTC time zone (no offset).
org.joda.time.DateTime dateTimeUtc = dateTimeInNewYork.toDateTime( org.joda.time.DateTimeZone.UTC );
// Move to Kolkata IN time zone (Standard offlet of +05:30).
org.joda.time.DateTime dateTimeInKolkata = dateTimeUtc.toDateTime( kolkataTimeZone ); // Or invoke this method on dateTimeInNewYork, does not matter which.

// All three of these date-time objects represent the same moment in the time-line of the Universe,
// but present themselves with different time-zone offsets.
System.out.println( "dateTimeInNewYork: " + dateTimeInNewYork );
System.out.println( "dateTimeUtc: " + dateTimeUtc );
System.out.println( "dateTimeInKolkata: " + dateTimeInKolkata );

When run…

dateTimeInNewYork: 2013-11-06T15:34:00.000-05:00
dateTimeUtc: 2013-11-06T20:34:00.000Z
dateTimeInKolkata: 2013-11-07T02:04:00.000+05:30

About Joda-Time…

// Joda-Time - The popular alternative to Sun/Oracle's notoriously bad date, time, and calendar classes bundled with Java 7 and earlier.
// http://www.joda.org/joda-time/

// Joda-Time will become outmoded by the JSR 310 Date and Time API introduced in Java 8.
// JSR 310 was inspired by Joda-Time but is not directly based on it.
// http://jcp.org/en/jsr/detail?id=310

// By default, Joda-Time produces strings in the standard ISO 8601 format.
// https://en.wikipedia.org/wiki/ISO_8601

// About Daylight Saving Time (DST): https://en.wikipedia.org/wiki/Daylight_saving_time

// Time Zone list: http://joda-time.sourceforge.net/timezones.html