如果您不另行指示Joda-Time,则formatter.parseDateTime()
将在您的默认时区解析为DateTime
。
因此,例如,如果您将本地时区设置为Europe / Dublin或Europe / London,则解析结果将是DateTime
的{{1}}(因为10月26日是夏季的最后一天)时间(DST)在这些时区)和一天中的小时将为0如您所预期。而且,如果您的Jenkins服务器的时区设置为UTC(这很常见),则您的字符串将在那里解析为2019-10-26T00:00:00.000+01:00
。显然,一天中的小时将是23。
如果您希望将字符串的偏移量保留在2019-10-25T23:00:00.000Z
中,则解决方法是:
DateTime
但是,请三思。一天中的小时仅相对于偏移量有意义。在夏令时结束的夜晚,您可以输入 DateTimeFormatter formatter = DateTimeFormat.forPattern("yyyy-MM-dd'T'HH:mm:ssZZ")
.withOffsetParsed();
的字符串,而在时钟更改后的一个小时后,您可以输入2019-10-27T01:00:00+01:00
。两个字符串的一天中的小时都是1,但是它们之间有一个小时。您是否真的想要相同的结果?如果有一天您收到一串2019-10-27T01:00:00+00:00
怎么办?
编辑:
您会建议什么,而不是使用withOffsetParsed()[?]
我首先建议您确定具有不同偏移量的字符串(例如2020-02-16T00:00:00-05:00
和2020-03-06T18:00:00+05:30
)所要获得的结果。你应该比我更了解。
通常建议的处理偏移量时间的做法是处理UTC中的所有内容。这可能是您已经找到并在注释中提到的解决方案的特例,其中指定了格式化程序上的时区:
2020-04-18T04:00:00-08:00
这保证了结果的一致性,显然与您在Jenkins服务器上获得的结果相同。在您的示例中为23。
PS如果这是新代码,则可能不应该使用Joda-Time。 The Joda-Time homepage说:
请注意,Joda-Time被认为是很大程度上“完成”的项目。
没有计划进行重大增强。如果使用Java SE 8,请迁移
到 DateTimeFormatter formatter = DateTimeFormat.forPattern("yyyy-MM-dd'T'HH:mm:ssZZ")
.withZoneUTC();
(JSR-310)。
本文链接:https://www.f2er.com/3101194.html