Java 8可选时间部分不起作用 [英] Java 8 optional time part not working

问题描述

我正在尝试为当前实施的可选时间部分创建日期时间格式

I am trying to create date time format for optional time part currently I implemented this

import java.time.*;
import java.time.format.DateTimeFormatter;
import java.time.format.DateTimeParseException;
import java.text.ParseException;

/* Name of the class has to be "Main" only if the class is public. */
class Ideone
{
    public static void main (String[] args) throws java.lang.Exception
    {
        System.out.println(Ideone.getDate("2017-07-01T00:00:00.0Z"));
        System.out.println(Ideone.getDate("2017-07-01T00:00:00.00Z"));
        System.out.println(Ideone.getDate("2017-07-01T00:00:00.000Z"));
    }
    
    public static LocalDateTime getDate(String date) {
        try {
           
            DateTimeFormatter formatter2 =
                DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss[.SSS]'Z'");
            LocalDateTime ldt = LocalDateTime.parse(date, formatter2);
            
            
            return ldt;
           
        } catch (DateTimeParseException ex) {
            return null;
        }
    }
}

有输出

空

2017-07-01T00:00

2017-07-01T00:00

2017-07-01T00:00

2017-07-01T00:00

现在我的问题是，为什么带有1个时间分数的日期不起作用，而带有2个和3个分数的日期呢?它应该接受1,2和3的分数吗?或只有3个分数?

Now my question is, why date with 1 time fraction is not working and it is working with 2 and 3 fractions? should it entertain 1,2 and 3 fractions? or only 3 fractions?

预先感谢

推荐答案

这似乎是一个错误.日期时间解析的毫秒部分似乎是Java 8中的一般错误，请参见此问题及其重复项.

This seems like a bug. The millisecond part of datetime parsing seems to be in general buggy in Java 8, see this issue and its duplicates.

相关报价:

但是，更糟糕的是，SSS模式因此最终使用了 宽容模式时适合的严格模式.由于目前 看台上，DateTimeFormatter.ofPattern("hhmmss.SSS")需要三个 最初要求为0时，以毫秒为单位的数字 到9(宽容的行为).

Worse however is that the SSS pattern has therefore ended up using strict mode when lenient mode would be appropriate. As it currently stands, DateTimeFormatter.ofPattern("hhmmss.SSS") requires three digits for milliseconds, when it was originally intended to require 0 to 9 (the lenient behaviour).

鉴于当前实现的SSS需要三位数字，因此非常令人惊讶的是，不应用相邻值解析.

Given that the current implementation requires three digits for SSS, it is thus very surprising that adjacent value parsing does not apply.

但是您似乎发现上述要求也不适用的情况.此外，即使上述问题处于已修复"状态，您的示例在Java 8和Java 9中似乎都存在问题:

But you seem to have found a case where requirement mentioned above does not apply either. In addition, even though the issue above is in state "fixed", your example seems to have issues in both java 8 and java 9:

>java -version
java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)

>javac Ideone.java

>java Ideone
null
2017-07-01T00:00
2017-07-01T00:00

>"c:\Program Files\Java\jdk1.8.0\bin"\javac Ideone.java

>"c:\Program Files\Java\jdk1.8.0\bin"\java Ideone
null
2017-07-01T00:00
2017-07-01T00:00

它应该接受1,2和3的分数吗?或只有3个分数?

should it entertain 1,2 and 3 fractions? or only 3 fractions?

基于报价，它应该仅为3，尽管最初的目的是0-9.

Based on the quote, it should be only 3, though originally intended to be 0-9.

这篇关于Java 8可选时间部分不起作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！