我正在尝试将dateTime字符串从Europe/London
时间转换为UTC。
谷歌搜索告诉我,UTC应该在Europe/London
时间后一小时,但当我尝试编写单元测试来验证时,计算的时间会产生相同的纪元时间。我也尝试过另一个时区(Asia/Kolkata
)并且工作正常。所以我很困惑,也不确定我做错了什么。
这是我正在使用的函数(dateString为2017-01-15 13:00:00
以及上述两个时区)
long getUTCTimeEpoch(final String dateString, @NonNull final String fromTimeZone) {
SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss", Locale.ROOT);
formatter.setTimeZone(TimeZone.getTimeZone(fromTimeZone));
try {
Date inputTime = formatter.parse(dateString);
Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone(fromTimeZone));
calendar.setTime(inputTime);
Calendar utcCalendar = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
utcCalendar.setTimeInMillis(calendar.getTimeInMillis());
return utcCalendar.getTime().getTime();
} catch (ParseException e) {
return 0;
}
}
这有效,
assertThat(getUTCTimeEpoch(timeString, "Asia/Kolkata"), is(1484465400000))
然后失败了,
assertThat(getUTCTimeEpoch(timeString, "Europe/London"), is(1484481600000))
答案 0 :(得分:2)
2017-01-15 13:00:00
在UTC中也是2017-01-15 13:00:00
,因为在 1月中,London is not in Daylight Saving Time (DST)及其本地时间与UTC相同。这就是为什么你得到millis值1484485200000
。
毫秒值1484481600000
相当于2017-01-15 12:00:00
(伦敦和UTC)。只需相应地更改值,测试就应该通过。
答案 1 :(得分:0)
在这种转换中,很多玩家都参与其中,一对是:
解决方案:使用java.time classes处理您需要的所有内容。
看着你,ZonedDateTime。