Comments on Vinod Singh: Date and TimeZone in Java

well if anyone's interested, i used jodatime. 3rd ...

2009-08-20T05:41:31.978+05:30

well if anyone's interested, i used jodatime. 3rd party java library. much accurate than java's Date and Calendar classes.

you can check it out
http://tech.chitgoks.com/2009/07/06/convert-timezone-using-joda-time/

The issue with above code is you took output objec...

2009-08-20T05:04:56.301+05:30

The issue with above code is you took output object from Calendar.getInstance(). That would give a instance in local timezone (e.g. IST in this case). Then date/time is set on this local calendar instance by several output.set(x,x) statements. When you print the date you see change in time and you assume that you successfully changed the timezone. Actually the 'first' object is giving you the other time.

You are mixing up the concepts of Calendar/Date/Ti...

2009-05-30T04:22:27.876+05:30

You are mixing up the concepts of Calendar/Date/Timezone. The reason Date.toString is always your local timezone is because your local machine's timezone is being used when formatting the output. In your example:
IST: Sat Mar 07 22:38:16 IST 2009
GMT: Sat Mar 07 17:08:16 IST 2009
are 2 different times and it is not a good idea to "overlook safely".

In fact, the same Date object can be output to any timezone's time using DateFormat with timezone set.
For example: with the same Date object, you can output to the following strings with DateFormat.

May 29, 2009 10:40:18 PM GMT
May 29, 2009 3:40:18 PM PDT
May 30, 2009 4:10:18 AM IST

i created a calendar object with timezone America/...

2009-05-13T13:05:00.000+05:30

i created a calendar object with timezone America/Los_Angeles dated dec 18, 2008 3:54pm. if changing it to Asia/Hong_Kong, result is not jan 1, 2009. any idea what could be wrong?

probably pst.getRawOffset() should be pst.getOffse...

2009-05-10T23:51:00.000+05:30

probably pst.getRawOffset() should be pst.getOffset(date.getTime());