Java Zulu和Offset的日期时间格式

我希望有一个单一的日期时间模式表达式能够：

• 使用偏移指示器序列化日期/瞬间，例如：2017-07-13T21:20:33.123+0000
• 使用zulu指示符分析字符串，例如：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'HH:MM:ss.SSSXX

将用于解析

Z

和

+0000

，但在序列化时不起作用。（例如使用UTC时，仅输出

Z

）

yyyy-MM-dd'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

格式输出偏移量

DateTimeFormatter formatter = new DateTimeFormatterBuilder()
    .append(ISO_LOCAL_DATE_TIME)
    .appendPattern("[x][X]")
    .toFormatter();

System.out.println(formatter.parse("2017-07-13T21:20:33.123+0200")
    .get(ChronoField.YEAR)); // 2017
System.out.println(formatter.parse("2017-07-13T21:20:33.123Z")
    .get(ChronoField.YEAR)); // 2017

编辑：

可以使用以下方法进行格式设置：

模式的日期时间格式（“yyyy-MM-dd'T:MM:ss.SSSxx”）

tl；博士 我确实找到了一种方法，但它不是一个漂亮的代码（它使用反射，如果可能的话，我个人不喜欢使用反射）

细节 我同意这些评论，有两个格式化程序（一个用于解析，另一个用于格式化）要容易得多

基本上是因为它似乎没有办法只使用一个格式化程序。我尝试了不同的可选模式组合，最接近的是：

DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSS[xx][XX]").withZone(ZoneOffset.UTC);

这将解析offset和Zulu，但在格式化时，输出以

+0000Z

结束（因为格式化程序在格式化时总是打印所有可选部分-似乎没有办法更改此行为）

我唯一能做的就是反射。首先，我创建一个

ZoneId

，然后将ID更改为空的

字符串

，并将规则与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=149990833}，ISO，解析为2017-07-13T21:20:33.123
{OffsetSeconds=0，InstantSeconds=149990833}，ISO，Z解析为2017-07-13T21:20:33.123

我必须添加

parseDefaulting（ChronoField.OFFSET_SECONDS，0）

，因为当找到

Z

时，没有设置

OffsetSeconds

字段，结果不能用于创建

OffsetDateTime

---

此格式化程序存在一些问题：

// 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));

• 当然，首先是使用反射。在生产环境中使用它是一个选择问题（我个人避免），如果

  SecurityManager

  配置为不允许它，它会抛出

  SecurityException

  （和）
• 更微妙和棘手的细节是，被解析的对象更喜欢

  区域

  ，而不是偏移量

因此，在第一种情况下（

dateStringOffset=2017-07-13T21:20:33.123+0200

），如果我尝试创建一个

Instant

或

ZoneDateTime

，它使用本地时间

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.time？乔达时间？三十个后场？老派的简化格式？当你说“序列化总是包括偏移量”时，你会同意使用Z而不是+0000，但应该总是有一些东西吗？@JonSkeet不，这是问题所在，它需要是

+0000

，而不是zulu指示符。添加了我尝试过的内容far@RobinJonsson开始永远不嫌晚。如果您尝试使用它，但遇到问题，我们将提供帮助。相信我，谷歌和Javadoc通常比人们更有用。@Robinjonson:如果你以前从未使用过

DateTimeFormatterBuilder

，那么你大概还没有尝试过用它来解决你的问题。Abhijit提出了一个您还没有尝试过的选项-怎么说“完全没有帮助”？在这一点上，我怀疑，虽然一种模式可能是可行的，但它可能比使用一种模式进行解析和格式化要复杂得多。（这没有解析时必须尝试两种不同的模式那么复杂…）格式化时会给出“+00Z”：（线程“main”java.time.temporal.UnsupportedTemporalTypeException:Unsupported字段：Year尝试格式化

即时

：（@Robinjonson

Instant

没有年份的概念，它是线性时间线中的一个点。@JonSkeet我没有检查格式，因为他没有问。@AbhijitSarkar:不，问题的关键是它可以解析+0000和Z，但它可以格式化为+0000:“重要的一点是序列化总是包含偏移量（+0000）”哇！非常好的研究！我也不喜欢使用反射。这只是更多的