Details
Enhancement
P3
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.
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
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 9 [ 14949 ] |
| Assignee | Roger Riggs [ rriggs ] |
| Status | New [ 10000 ] | Open [ 1 ] |
| Assignee | Roger Riggs [ rriggs ] | Nadeesh Tv [ ntv ] |
Stephen, Roger - Could I solve https://bugs.openjdk.java.net/browse/JDK-8015989? also as part of this bug fix
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Understanding | Cause Known [ 10000 ] |
8015989 is based on a CLDR ticket that has been withdrawn as moot.
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
Suppose a pattern like +Hmm, or +HMMss
It is obvious how input would be parsed for:
+123
-23456
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
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
[~scolebourne] [~rriggs] Could you please confirm that Single digit hour support only in lenient mode?
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).
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).
@Stephen Did you mean "H" should parse both 1 and 12 irrespective of the mode (strict or lenient)?
If the pattern contains "H" then it has to parse either 1 or 2 digits regardless of mode.
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
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
| Labels | jdk9-fc-request |
| 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 |
| Labels | jdk9-fc-request | jdk9-fc-request jdk9-fc-yes |
URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0881ab3faeb4
User: ntv
Date: 2016-07-28 10:29:03 +0000
User: ntv
Date: 2016-07-28 10:29:03 +0000
| Status | In Progress [ 3 ] | Resolved [ 5 ] |
| Resolved In Build | team [ 17324 ] | |
| Understanding | Cause Known [ 10000 ] | |
| Resolution | Fixed [ 1 ] |
URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0881ab3faeb4
User: amurillo
Date: 2016-08-03 16:28:12 +0000
User: amurillo
Date: 2016-08-03 16:28:12 +0000
| Resolved In Build | team [ 17324 ] | master [ 18256 ] |
| Resolved In Build | master [ 18256 ] | b130 [ 17604 ] |
| Labels | jdk9-fc-request jdk9-fc-yes | jdk9-fc-request jdk9-fc-yes jsr379-annex2-tbd |
| Labels | jdk9-fc-request jdk9-fc-yes jsr379-annex2-tbd | jdk9-fc-request jdk9-fc-yes jsr379-annex1 |
| Link | This issue csr of CCC-8066806 [ CCC-8066806 ] |
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).