问题
I am trying to convert from one timezone to another using Joda-Time.
final DateTimeZone fromTimeZone = DateTimeZone.forID("America/Los_Angeles");
final DateTimeZone toTimeZone = DateTimeZone.forID(toTimeZoneString);
DateTime convertedStart = new DateTime(start, fromTimeZone).withZone(toTimeZone);
Date finalS = convertedStart.toDate();
I see that finalS loses the timezone and is reverted back to the original timezone when I do .toDate(). convertedStart is correctly converted.
start is in format -> Wed Jun 04 18:15:38 GMT 2014.
Example:
start: Wed Jun 04 18:15:38 GMT 2014
toTimeZoneString is Asia/Kolkata
convertedStart : 2014-06-05T06:45:38.409+05:30
finalS: Wed Jun 04 18:15:38 GMT 2014
Why is this happening?
回答1:
Since you refuse to post a complete working example of code, I'll make do with a little demo as an answer.
Example code using Joda-Time 2.3.
Use a java.util.Date only when forced, such as outputs/inputs to other classes.
java.util.Date dateIn = new java.util.Date(); // Avoid java.util.Date when possible.
Convert the Date to a Joda-Time DateTime, and assign a time zone. I am arbitrarily choosing UTC. Most or all of your business logic should be done in UTC unless business rules dictate use of a local time zone.
DateTime dateTimeUtc = new DateTime( dateIn, DateTimeZone.UTC ); // Convert Date to DateTime, assign UTC time zone.
Adjust the time zone from UTC to west coast of the United States. Use proper time zone names (mostly continent/cityOrRegion) rather than 3 or 4 letter codes which are neither standardized nor unique.
DateTimeZone timeZoneLos_Angeles = DateTimeZone.forID( "America/Los_Angeles" ); // Adjust time zone to United States.
DateTime dateTimeLos_Angeles = dateTimeUtc.withZone( timeZoneLos_Angeles );
Adjust to India time zone, five and a half hours ahead of UTC. Note that for thread-safety Joda-Time uses immutable objects. Rather than make changes, we create a new instance while copying values from the original.
DateTimeZone timeZoneKolkata = DateTimeZone.forID( "Asia/Kolkata" ); // Adjust time zone to India.
DateTime dateTimeKolkata = dateTimeLos_Angeles.withZone( timeZoneKolkata );
Convert back to a j.u.Date if required.
java.util.Date dateOut = dateTimeKolkata.toDate();
Dump to console. Notice that, by default, Joda-Time creates String representations according to the ISO 8601 standard.
System.out.println( "dateIn: " + dateIn ); // j.u.Date's "toString" method applies JVM's default time zone. Very confusing, as a j.u.Date has no time zone.
System.out.println( "dateTimeUtc: " + dateTimeUtc );
System.out.println( "dateTimeLos_Angeles: " + dateTimeLos_Angeles );
System.out.println( "dateTimeKolkata: " + dateTimeKolkata );
System.out.println( "dateOut: " + dateOut ); // j.u.Date's "toString" method uses a terrible format. Use only in a pinch like debugging, never in production.
System.out.println( "Milliseconds since Unix epoch: " + dateIn.getTime() + " | " + dateTimeUtc.getMillis() + " | " + dateTimeLos_Angeles.getMillis() + " | " + dateTimeKolkata.getMillis() + " | " + dateOut.getTime() );
When run…
dateIn: Wed Jun 04 13:51:01 PDT 2014
dateTimeUtc: 2014-06-04T20:51:01.593Z
dateTimeLos_Angeles: 2014-06-04T13:51:01.593-07:00
dateTimeKolkata: 2014-06-05T02:21:01.593+05:30
dateOut: Wed Jun 04 13:51:01 PDT 2014
Milliseconds since Unix epoch: 1401915061593 | 1401915061593 | 1401915061593 | 1401915061593 | 1401915061593
Understand that all of these date-time values represent the same simultaneous moment, the same point on the timeline of the Universe. Notice how the Strings vary across dates (June 4th and 5th), yet we are seeing the same moment. Imagine three people in Reykjavík, Los Angeles, and Kolkata all looking at their pocketwatch/phone at the same moment (wall-clock time).
来源：https://stackoverflow.com/questions/24044810/joda-time-datetime-todate-reverts-back-timezone