Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8066806

java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

    Details

    • Subcomponent:
    • Introduced In Version:
      8
    • Resolved In Build:
      b130
    • CPU:
      generic
    • OS:
      generic

      Description

      There's no way to parse a single digit hour in the offset. Example:

        2011-01-20 02:55:07.532941 -8:00

      The spec needs to be modified to cover this case and the code enhanced to support it.

      The only workaround is to parse the date/time separately, use a hand coded parser for the offset and combine the LocalDateTime with the hand parsed offset. Not an easy work around.

      I have run across some occurrences of this though I can't say how common it is.

        Activity

        dsurber Douglas Surber created issue -
        Hide
        scolebourne Stephen Colebourne added a comment -
        One possibility is to argue that lenient parsing should handle this. ie. to make this code work:

            DateTimeFormatter f = new DateTimeFormatterBuilder().parseLenient().appendOffset("+HH:MM", "+00:00").toFormatter();
            System.out.println(f.parse("+8:00", ZoneOffset::from));

        Given the spec doesn't discuss strict vs lenient for appendOffset() one might be able to argue it as a bug.

        Otherwise, in JDK 9, patterns will have to be added matching all the existing patterns for appendOffset() that print/parse a single digit, such as "+H:mm" (9 patterns in total).
        Show
        scolebourne Stephen Colebourne added a comment - One possibility is to argue that lenient parsing should handle this. ie. to make this code work:     DateTimeFormatter f = new DateTimeFormatterBuilder().parseLenient().appendOffset("+HH:MM", "+00:00").toFormatter();     System.out.println(f.parse("+8:00", ZoneOffset::from)); Given the spec doesn't discuss strict vs lenient for appendOffset() one might be able to argue it as a bug. Otherwise, in JDK 9, patterns will have to be added matching all the existing patterns for appendOffset() that print/parse a single digit, such as "+H:mm" (9 patterns in total).
        rriggs Roger Riggs made changes -
        Field Original Value New Value
        Fix Version/s 9 [ 14949 ]
        rriggs Roger Riggs made changes -
        Assignee Roger Riggs [ rriggs ]
        rriggs Roger Riggs made changes -
        Status New [ 10000 ] Open [ 1 ]
        rriggs Roger Riggs made changes -
        Assignee Roger Riggs [ rriggs ] Nadeesh Tv [ ntv ]
        Hide
        ntv Nadeesh Tv (Inactive) added a comment -
        Stephen, Roger - Could I solve https://bugs.openjdk.java.net/browse/JDK-8015989? also as part of this bug fix
        Show
        ntv Nadeesh Tv (Inactive) added a comment - Stephen, Roger - Could I solve https://bugs.openjdk.java.net/browse/JDK-8015989? also as part of this bug fix
        ntv Nadeesh Tv (Inactive) made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Understanding Cause Known [ 10000 ]
        Hide
        rriggs Roger Riggs added a comment -
        8015989 is based on a CLDR ticket that has been withdrawn as moot.
        Show
        rriggs Roger Riggs added a comment - 8015989 is based on a CLDR ticket that has been withdrawn as moot.
        Hide
        rriggs Roger Riggs added a comment -
        Adding patterns without delimiters might make the parsing confusing:
        Suppose a pattern like +Hmm, or +HMMss
        It is obvious how input would be parsed for:
           +123
            -23456
        Show
        rriggs Roger Riggs added a comment - Adding patterns without delimiters might make the parsing confusing: Suppose a pattern like +Hmm, or +HMMss It is obvious how input would be parsed for:    +123     -23456
        Hide
        scolebourne Stephen Colebourne added a comment -
        The most important case is handling +0 to +9 and -1 to -9, ie. hours only. That would only be one new pattern +H.

        That said, there is a good case for the parser to just accept a single digit in colon-deliminated formats if in lenient mode. ie patterns +HH, +HH:MM, +HH:mm, +HH:MM:SS, +HH:MM:ss, +HH:mm:ss would all accept single digits in lenient mode
        Show
        scolebourne Stephen Colebourne added a comment - The most important case is handling +0 to +9 and -1 to -9, ie. hours only. That would only be one new pattern +H. That said, there is a good case for the parser to just accept a single digit in colon-deliminated formats if in lenient mode. ie patterns +HH, +HH:MM, +HH:mm, +HH:MM:SS, +HH:MM:ss, +HH:mm:ss would all accept single digits in lenient mode
        Hide
        ntv Nadeesh Tv (Inactive) added a comment -
        [~scolebourne] [~rriggs] Could you please confirm that Single digit hour support only in lenient mode?
        Show
        ntv Nadeesh Tv (Inactive) added a comment - [~scolebourne] [~rriggs] Could you please confirm that Single digit hour support only in lenient mode?
        Hide
        scolebourne Stephen Colebourne added a comment -
        Although the OP only mentions parsing, I consider the requirement is to support this in both formatting and parsing.

        To support this in parsing requires a new pattern for each of the current variants:

        +H
        +Hmm
        +H:mm
        +HMM
        +H:MM
        +HMMss
        +H:MM:ss
        +HMMSS
        +H:MM:SS
        +Hmmss
        +H:mm:ss

        Given an offset of +05:30, these would output 5 for the hour part.
        Given an offset of +11:30, these would output 11 for the hour part.

        When parsing, any pattern that includes "H" rather than "HH" would need to accept either one or two digits for the hour. As Roger points out, for a pattern like "HMMss", this involves working out whether there are 3, 4, 5 or 6 digits to parse. (3 means HMM, 4 means HHMM, 5 means HMMSS, 6 means HHMMSS)

        Note that we will not be able to add support for single digit minutes or seconds in the future (but there is no demand for that).
        Show
        scolebourne Stephen Colebourne added a comment - Although the OP only mentions parsing, I consider the requirement is to support this in both formatting and parsing. To support this in parsing requires a new pattern for each of the current variants: +H +Hmm +H:mm +HMM +H:MM +HMMss +H:MM:ss +HMMSS +H:MM:SS +Hmmss +H:mm:ss Given an offset of +05:30, these would output 5 for the hour part. Given an offset of +11:30, these would output 11 for the hour part. When parsing, any pattern that includes "H" rather than "HH" would need to accept either one or two digits for the hour. As Roger points out, for a pattern like "HMMss", this involves working out whether there are 3, 4, 5 or 6 digits to parse. (3 means HMM, 4 means HHMM, 5 means HMMSS, 6 means HHMMSS) Note that we will not be able to add support for single digit minutes or seconds in the future (but there is no demand for that).
        Hide
        ntv Nadeesh Tv (Inactive) added a comment - - edited
        @Stephen Did you mean "H" should parse both 1 and 12 irrespective of the mode (strict or lenient)?
        Show
        ntv Nadeesh Tv (Inactive) added a comment - - edited @Stephen Did you mean "H" should parse both 1 and 12 irrespective of the mode (strict or lenient)?
        Hide
        scolebourne Stephen Colebourne added a comment -
        If the pattern contains "H" then it has to parse either 1 or 2 digits regardless of mode.
        Show
        scolebourne Stephen Colebourne added a comment - If the pattern contains "H" then it has to parse either 1 or 2 digits regardless of mode.
        Show
        ntv Nadeesh Tv (Inactive) added a comment - http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/041487.html
        Hide
        ntv Nadeesh Tv (Inactive) added a comment -
        FC Extension Request:

        Status: Review ongoing in core-libs-dev http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/041487.html

        Justification:
         • At present, java.time.format.DateTimeFormatter cannot parse an offset with single digit
           hour. Since most of the countries time zone have single digit hour (America/Newyork-5,
           Germany/Berlin +2 etc..) in offset, we should enhance the offset by
           introducing following patterns:
              +H, +Hmm, +H:mm, +HMM, +H:MM, +HMMss, +H:MM:ss,
              +HMMSS, +H:MM:SS, +Hmmss, +H:mm:ss
           this enhancement will be useful to most developers.

        Remaining work to be done:

        Test cases for lenient scenario

        Compatibility Risk:
          • Minimal (no existing tests will fail)

        Change will be integrated (locally) by: 2016-06-24
        Show
        ntv Nadeesh Tv (Inactive) added a comment - FC Extension Request: Status: Review ongoing in core-libs-dev http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/041487.html Justification:  • At present, java.time.format.DateTimeFormatter cannot parse an offset with single digit    hour. Since most of the countries time zone have single digit hour (America/Newyork-5,    Germany/Berlin +2 etc..) in offset, we should enhance the offset by    introducing following patterns:       +H, +Hmm, +H:mm, +HMM, +H:MM, +HMMss, +H:MM:ss,       +HMMSS, +H:MM:SS, +Hmmss, +H:mm:ss    this enhancement will be useful to most developers. Remaining work to be done: Test cases for lenient scenario Compatibility Risk:   • Minimal (no existing tests will fail) Change will be integrated (locally) by: 2016-06-24
        ntv Nadeesh Tv (Inactive) made changes -
        Labels jdk9-fc-request
        mr Mark Reinhold made changes -
        Summary java.time.format.DateTimeFormatter cannot parse an offset with single digit hour. java.time.format.DateTimeFormatter cannot parse an offset with single digit hour
        briangoetz Brian Goetz made changes -
        Labels jdk9-fc-request jdk9-fc-request jdk9-fc-yes
        Hide
        hgupdate HG Updates added a comment -
        URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0881ab3faeb4
        User: ntv
        Date: 2016-07-28 10:29:03 +0000
        Show
        hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0881ab3faeb4 User: ntv Date: 2016-07-28 10:29:03 +0000
        hgupdate HG Updates made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Resolved In Build team [ 17324 ]
        Understanding Cause Known [ 10000 ]
        Resolution Fixed [ 1 ]
        Hide
        hgupdate HG Updates added a comment -
        URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0881ab3faeb4
        User: amurillo
        Date: 2016-08-03 16:28:12 +0000
        Show
        hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0881ab3faeb4 User: amurillo Date: 2016-08-03 16:28:12 +0000
        hgupdate HG Updates made changes -
        Resolved In Build team [ 17324 ] master [ 18256 ]
        hgupdate HG Updates made changes -
        Resolved In Build master [ 18256 ] b130 [ 17604 ]
        iris Iris Clark made changes -
        Labels jdk9-fc-request jdk9-fc-yes jdk9-fc-request jdk9-fc-yes jsr379-annex2-tbd
        iris Iris Clark made changes -
        Labels jdk9-fc-request jdk9-fc-yes jsr379-annex2-tbd jdk9-fc-request jdk9-fc-yes jsr379-annex1
        darcy Joe Darcy made changes -
        Link This issue csr of CCC-8066806 [ CCC-8066806 ]

          People

          • Assignee:
            ntv Nadeesh Tv (Inactive)
            Reporter:
            dsurber Douglas Surber
          • Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: