Java Date 8上的Java Instant.parse [英] Java Instant.parse on Date java 8

问题描述

我有一些旧版KML文档，其中包括时间戳记条目. 为什么使用即时分析时，以下日期无效?假定这两种方法都可以解析ISO 8601格式的日期.

I have some legacy KML documents which includes a time stamp entry. Why is the below date not valid when using Instant to parse? Both methods are suppose to parse ISO 8601 formatted dates.

String dateString ="2017-12-04T08:06:60Z"

String dateString = "2017-12-04T08:06:60Z"

使用

java.time.Instant.parse(dateString)

引发错误

"DateTimeParseException Text 2017-12-04T08:06:60Z could not be parsed at index 0."

但是，使用

Date myDate =   javax.xml.bind.DatatypeConverter.parseDateTime( dateString )

myDate已正确解析....

myDate is parsed correctly....

推荐答案

1. 60秒不是有效时间.这意味着2017-12-04T08:06:60Z是无效的，如果它是60秒，那么分钟应该增加了，而您的时间将是2017-12-04T08:07:00Z

2. 使用有效日期，然后解析 String 可以正常工作:

1. 60 seconds isn't a valid time. Meaning that this is invalid 2017-12-04T08:06:60Z, if it was 60 seconds then the minute should have incremented and your time would be 2017-12-04T08:07:00Z

2. Using a valid date and then parsing the String would work just fine:

String date = "2017-12-04T08:07:00Z";
System.out.println(Instant.parse(date));

java.time也忽略了 leap 秒.从文档:

Also java.time ignores leap seconds. From the docs:

使用JSR-310 API的Java时间刻度的实现不是 需要提供任何亚秒级精度的时钟，或者 单调或平稳地前进. 因此实施 不需要实际执行UTC-SLS转换或以其他方式执行 知道leap秒.但是，JSR-310确实要求 实现必须记录他们在定义 代表当前时刻的时钟.有关详细信息，请参见时钟. 可用时钟.

Implementations of the Java time-scale using the JSR-310 API are not required to provide any clock that is sub-second accurate, or that progresses monotonically or smoothly. Implementations are therefore not required to actually perform the UTC-SLS slew or to otherwise be aware of leap seconds. JSR-310 does, however, require that implementations must document the approach they use when defining a clock representing the current instant. See Clock for details on the available clocks.

这篇关于Java Date 8上的Java Instant.parse的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！