可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
I am curious about timezone in Java. I want to get UTC time in milliseconds from a device and send to server. Server will convert it to local timezone when it displays time to users. Timezone in my system is Australia/Sydney( UTC + 11:00), and I have got the result below when I tested timezone:
int year = 2014; int month = 0; int date = 14; int hourOfDay = 11; int minute = 12; int second = 0; Calendar c1 = Calendar.getInstance(); c1.set(year, month, date, hourOfDay, minute, second); SimpleDateFormat sdf = new SimpleDateFormat("dd/MM/yyyy HH:mm:ss z"); System.out.println(sdf.format(c1.getTime())); Calendar c2 = Calendar.getInstance(TimeZone.getTimeZone("UTC")); c2.set(year, month, date, hourOfDay, minute, second); System.out.println(sdf.format(c2.getTime()));
output:
14/01/2014 11:12:00 EST 14/01/2014 22:12:00 EST
I thought I could have 13/01/2014 00:12:00 for c2 because UTC time is 11 hours later than mine. Does not Calendar work the way I expect?
Your help would be appreciated.
EDIT
Added z to display timezone. This makes me more confused because Mac says its timezone is (AEDT) Australian Eastern Daylight Time but Java is EST. Anyway still result is different because EST is UTC-5 hours.
回答1:
You probably meant to set the timezone on your formatter, not the Calendar (or in addition the the Calendar, it is not 100% clear what you mean to accomplish)! The timezone used to create the human representation comes from the SimpleDateFormat. All "timezone" information is lost from the Calendar when you convert it back into a java.util.Date by calling getTime()
.
The code:
Calendar c2 = Calendar.getInstance(TimeZone.getTimeZone("UTC")); c2.set(year, month, date, hourOfDay, minute, second); System.out.println(sdf.format(c2.getTime()));
is printing 14/01/2014 10:12:00
because 11AM UTC displayed in Syndey (the timezone of your formatter) is 10PM! (use HH in the format for 24 hour time)
This would print what it seems like you meant to do:
SimpleDateFormat sdf = new SimpleDateFormat("dd/MM/yyyy hh:mm:ss z"); System.out.println(sdf.format(c1.getTime())); sdf.setTimeZone(TimeZone.getTimeZone("UTC")); System.out.println(sdf.format(c1.getTime()));
The concept of 'UTC milliseconds' is meaningless. A quantity of milliseconds is just a fixed point in history, it has no timezone associated with it. We add a timezone to it to convert it into human-readable representations.
edit: Yes, the ambiguity of using 'EST' for both (US) Eastern Time and (Australian) Eastern Time has been a pitfall in Java since forever.
回答2:
Three-Letter Codes
You should avoid using 3 or 4 letter time zone codes such as EST
or IST
. They are neither standard nor unique.
Use proper time zone names, mostly Continent/CityOrRegion
such as America/Montreal
or Asia/Kolkata
.
Joda-Time
The java.util.Date/Calendar classes are notoriously bad. Avoid using them. Use either Joda-Time or, in Java 8, the new java.time.* classes defined by JSR 310 and inspired by Joda-Time.
Time Zone
In Joda-Time, a DateTime instance knows its own time zone.
Sydney Australia has a standard time of 10 hours ahead of UTC/GMT, and a Daylight Saving Time (DST) of 11 hours ahead. DST applies to the date specified by the question.
Tip: Don't think like this…
UTC time is 11 hours later than mine
Think like this…
Sydney DST is 11 hours ahead of UTC/GMT.
Date-time work becomes easier and less error-prone if you think, work, and store in UTC/GMT. Only convert to localized date-time for presentation in the user-interface. Think globally, display locally. Your users and your servers can easily move to other time zones, so forget about your own time zone. Always specify a time zone, never assume or rely on default.
Example Code
Here is some example code using Joda-Time 2.3 and Java 8.
// Better to specify a time zone explicitly than rely on default. // Use time zone names, not 3-letter codes. // This list is not quite up-to-date (read page for details): http://joda-time.sourceforge.net/timezones.html DateTimeZone timeZone = DateTimeZone.forID("Australia/Sydney"); DateTime dateTime = new DateTime(2014, 1, 14, 11, 12, 0, timeZone); DateTime dateTimeUtc = dateTime.toDateTime(DateTimeZone.UTC); // Built-in constant for UTC (no time zone offset).
Dump to console…
System.out.println("dateTime: " + dateTime); System.out.println("dateTimeUtc: " + dateTimeUtc);
When run…
dateTime: 2014-01-14T11:12:00.000+11:00 dateTime in UTC: 2014-01-14T00:12:00.000Z