我希望有一个日期时间模式表达式能够:
- 使用偏移量指示器序列化日期/时刻,例如:2017-07-13T21:20:33.123+0000
- 使用祖鲁指示符解析字符串,例如:2017-07-13T21:20:33.123Z
- 解析带有偏移量的字符串,例如:2017-07-13T21:20:33.123+0200
重要的是序列化始终包含偏移量 (+0000
)
并且反序列化可以处理这两种情况(Z
或 +0000
)
到目前为止我尝试过的:
我使用的是 JDK8,带有新的内置 java.time
包。我尝试使用以下模式创建 java.time.DateTimeFormatter
:
yyyy-MM-dd'T'HH:mm:ss.SSSXX
将适用于解析 Z
和 +0000
但不能序列化时不起作用。 (例如,当使用 UTC 时,它仅输出 Z
)
yyyy-MM-dd'T'HH:mm:ss.SSSZ
会解析 +0000
但不会解析 Z
如果存在
是否可以有一种表达方式来表达这一点?
下面是完全可测试的代码:
import java.time.Instant;
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;
public class DateTimeFormatterTest {
public static void main(String[] args) {
final DateTimeFormatter dtf = DateTimeFormatter
.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSZ")
.withZone(ZoneId.of("UTC"));
final Instant now = Instant.now();
System.out.println(dtf.format(now)); //THIS IS OK
final String dateStringOffset = "2017-07-13T21:20:33.123+0200";
System.out.println(dtf.parse(dateStringOffset)); //THIS IS OK
final String dateStringZulu = "2017-07-13T21:20:33.123Z";
System.out.println(dtf.parse(dateStringZulu)); //THIS IS NOT OK
}
}
我的印象是,将 XX
附加到模式末尾会强制它始终以 +0000
格式输出偏移量
最佳答案
tl;博士
我实际上找到了一种方法,但它不是一个漂亮的代码(它使用反射,如果可能的话,我个人宁愿不使用反射)。
详细信息
我同意这些评论,即拥有 2 个格式化程序(一个用于解析,另一个用于格式化)要容易得多。
基本上是因为它似乎无法仅使用一个格式化程序来完成此操作。我尝试过不同的可选模式组合,最接近的是:
DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSS[xx][XX]").withZone(ZoneOffset.UTC);
这会解析偏移量和 Zulu,但是在格式化时,输出以 +0000Z
结尾(因为格式化程序在格式化时总是打印所有可选部分 - 它似乎没有办法改变这种行为)。
我能做到的唯一方法是使用反射。首先,我创建一个 ZoneId
,然后将 ID 更改为空的 String
以及匹配 UTC 的规则(因此它的行为就像 UTC)。然后我在格式化程序中使用这个修改后的区域:
// get any zone, just to get a valid ZoneId
ZoneId zone = ZoneId.of("Europe/London");
// change ID to empty string (so it's not printed by the formatter)
Field field = zone.getClass().getDeclaredField("id");
field.setAccessible(true);
field.set(zone, "");
// change zone rules to match UTC (so this zone becomes a "copy" of UTC)
field = zone.getClass().getDeclaredField("rules");
field.setAccessible(true);
field.set(zone, ZoneOffset.UTC.getRules());
DateTimeFormatter dtf = new DateTimeFormatterBuilder()
// date and time
.appendPattern("yyyy-MM-dd'T'HH:mm:ss.SSS")
// optional offset - prints +0000 when it's zero (instead of Z)
.optionalStart().appendOffset("+HHMM", "+0000").optionalEnd()
// optional zone id (so it parses "Z")
.optionalStart()
.appendZoneId()
// add default value for offset seconds when field is not present
.parseDefaulting(ChronoField.OFFSET_SECONDS, 0)
.optionalEnd()
// create formatter using the "UTC-cloned" zone
.toFormatter().withZone(zone);
System.out.println(dtf.format(ZonedDateTime.now()));
System.out.println(dtf.format(Instant.now()));
String dateStringOffset = "2017-07-13T21:20:33.123+0200";
System.out.println(dtf.parse(dateStringOffset));
String dateStringZulu = "2017-07-13T21:20:33.123Z";
System.out.println(dtf.parse(dateStringZulu));
输出为:
2017-07-12T13:39:49.695+0000
2017-07-12T13:39:49.695+0000
{OffsetSeconds=7200, InstantSeconds=1499980833},ISO, resolved to 2017-07-13T21:20:33.123
{OffsetSeconds=0, InstantSeconds=1499980833},ISO,Z resolved to 2017-07-13T21:20:33.123
我必须添加 parseDefaulting(ChronoField.OFFSET_SECONDS, 0)
因为当找到 Z
时,未设置 OffsetSeconds
字段并且结果无法用于创建 OffsetDateTime
。
此格式化程序存在一些问题:
- 首先当然是反射的使用。在生产环境中使用它是一个选择问题(我个人避免它),如果
SecurityManager
配置为不允许它(并且 some other issues ) - 更微妙和棘手的细节是解析的对象更喜欢
区域
而不是偏移量。
因此,在第一种情况下 (dateStringOffset = 2017-07-13T21:20:33.123+0200
),如果我尝试创建 Instant
或 ZonedDateTime
,它使用本地时间21:20:33
和UTC时区,忽略偏移量+0200
:
dtf.parse(dateStringOffset, Instant::from); // Wrong: 2017-07-13T21:20:33.123Z
dtf.parse(dateStringOffset, ZonedDateTime::from); // Wrong: 2017-07-13T21:20:33.123Z[]
要获得正确的结果,我必须使用 OffsetDateTime
:
dtf.parse(dateStringOffset, OffsetDateTime::from); // Correct: 2017-07-13T21:20:33.123+02:00
对于第二种情况,因为它采用 UTC (Z
),所以所有三种类型都有效。但我建议始终将结果解析为 OffsetDateTime
,然后将其转换为其他类型。
或者保持简单,只使用 2 个格式化程序:
// parse both offset and Z
DateTimeFormatter parser = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSS[xx][XX]");
// format with offset (and +0000 instead of Z)
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSxx").withZone(ZoneOffset.UTC);
这没有上面的副作用 - 它正确地解析了偏移量:
parser.parse(dateStringOffset, Instant::from); // 2017-07-13T19:20:33.123Z (Instant is always in UTC)
parser.parse(dateStringOffset, ZonedDateTime::from); // 2017-07-13T21:20:33.123+02:00
parser.parse(dateStringOffset, OffsetDateTime::from); // 2017-07-13T21:20:33.123+02:00
关于java - Zulu 和 Offset 的日期时间格式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45050930/