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

Adjacent value parsing not supported for Localized Patterns

    Details

    • Subcomponent:
    • Resolved In Build:
      b151
    • CPU:
      generic
    • OS:
      generic

      Description

      FULL PRODUCT VERSION :


      A DESCRIPTION OF THE PROBLEM :
      DateTimeFormatter.ofPattern("YYYYww").parse("201550") fails with "java.time.format.DateTimeParseException: Text '201550' could not be parsed at index 0" and I think it shouldn't.
      The same text and pattern work with SimpleDateFormat, so does DateTimeFormatter.ofPattern("YYww").parse("1550").
      It fails in java.time.format.DateTimeFormatterBuilder.NumberPrinterParser.parse(DateTimeParseContext, CharSequence, int), line 2695
      http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/6ea3aea950d1/src/share/classes/java/time/format/DateTimeFormatterBuilder.java#l2695
      However, parsing "2015 50" with "YYYY ww" works fine.

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      DateTimeFormatter.ofPattern("YYYYww").parse("201550")

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      {WeekBasedYear[WeekFields[MONDAY,4]]=2015, WeekOfWeekBasedYear[WeekFields[MONDAY,4]]=50},ISO
      ACTUAL -
      IllegalArgumentException: Text '201550' could not be parsed at index 0

      REPRODUCIBILITY :
      This bug can be reproduced always.

        Activity

        Hide
        psonal Pallavi Sonal added a comment -
        Attached is the test case :
        JDK 8 - Fail
        JDK 8u60 - Fail
        JDK 8u72 - Fail
        JDK 9 EA b93- Fail
        Show
        psonal Pallavi Sonal added a comment - Attached is the test case : JDK 8 - Fail JDK 8u60 - Fail JDK 8u72 - Fail JDK 9 EA b93- Fail
        Hide
        scolebourne Stephen Colebourne added a comment -
        The desired behaviour is called "adjacent value parsing" in the documentation. It applies to each call made to DateTimeFormatterBuilder.appendValue*(). The pattern letters "y", "M" and "d" call appendValue(), but the pattern letters "Y" and "w" do not. This is because those pattern letters are localized, altering their behaviour based on the configured locale.

        The desired behaviour can be achieved by directly using the builder as follows:

        DateTimeFormatter f = new DateTimeFormatterBuilder()
                .appendValue(IsoFields.WEEK_BASED_YEAR, 4)
                .appendValue(IsoFields.WEEK_OF_WEEK_BASED_YEAR, 2)
                .toFormatter();

        Given the difficulty of the adjacent value parsing code, and the existence of a suitable alternative, I'd suggest closing this as Won't Fix.
        Show
        scolebourne Stephen Colebourne added a comment - The desired behaviour is called "adjacent value parsing" in the documentation. It applies to each call made to DateTimeFormatterBuilder.appendValue*(). The pattern letters "y", "M" and "d" call appendValue(), but the pattern letters "Y" and "w" do not. This is because those pattern letters are localized, altering their behaviour based on the configured locale. The desired behaviour can be achieved by directly using the builder as follows: DateTimeFormatter f = new DateTimeFormatterBuilder()         .appendValue(IsoFields.WEEK_BASED_YEAR, 4)         .appendValue(IsoFields.WEEK_OF_WEEK_BASED_YEAR, 2)         .toFormatter(); Given the difficulty of the adjacent value parsing code, and the existence of a suitable alternative, I'd suggest closing this as Won't Fix.
        Hide
        rriggs Roger Riggs added a comment -
        The 'fix' for this is to document/specify the behavior.

        The DateTimeFormatBuilder does not support adjacent value parsing for locale based patterns
        because the locale is not known when the builder is constructed,
        it is supplied when the format is used to parse an input string.

        Perhaps something like this can be added as a footnote or note on the table of patterns in DateTimeFormatter.

        And it can describe the workaround.
        Show
        rriggs Roger Riggs added a comment - The 'fix' for this is to document/specify the behavior. The DateTimeFormatBuilder does not support adjacent value parsing for locale based patterns because the locale is not known when the builder is constructed, it is supplied when the format is used to parse an input string. Perhaps something like this can be added as a footnote or note on the table of patterns in DateTimeFormatter. And it can describe the workaround.
        Hide
        scolebourne Stephen Colebourne added a comment -
        Given that we have managed to extend adjacent value parsing in other places, it seems reasonable to extend it here for "ww" and "W". Many users first interaction with parsing will be via the patterns, so we should go the extra mile here.

        As before, WeekBasedFieldPrinterParser will have to be changed to extend NumberPrinterParser and the necessary glue added (only for the two cases "ww" and "W". There is no need to alter "YYYY" or "YY" (partly because these would be more difficult).
        Show
        scolebourne Stephen Colebourne added a comment - Given that we have managed to extend adjacent value parsing in other places, it seems reasonable to extend it here for "ww" and "W". Many users first interaction with parsing will be via the patterns, so we should go the extra mile here. As before, WeekBasedFieldPrinterParser will have to be changed to extend NumberPrinterParser and the necessary glue added (only for the two cases "ww" and "W". There is no need to alter "YYYY" or "YY" (partly because these would be more difficult).
        Hide
        ntv Nadeesh Tv added a comment -
        [~scolebourne] I have a doubt about the impact of the proposed fix.
        We can successfully parse DateTimeFormatter.ofPattern("YYYYww").parse("201550") but how this will be useful.
        For eg : We can not get a LocaDate from it becuase other pattern letter like 'Y', 'e' etc will not take part in adjacentvalue parsing.
        Show
        ntv Nadeesh Tv added a comment - [~scolebourne] I have a doubt about the impact of the proposed fix. We can successfully parse DateTimeFormatter.ofPattern("YYYYww").parse("201550") but how this will be useful. For eg : We can not get a LocaDate from it becuase other pattern letter like 'Y', 'e' etc will not take part in adjacentvalue parsing.
        Hide
        scolebourne Stephen Colebourne added a comment -
        Adjacent value parsing is allowed to have one element at the start that is variable width. However all elements must be NumberPrinterParser called through appendValue(). For example, "yyyyMMdd":

        - yyyy - variable width, but is a NumberPrinterParser called through appendValue()
        - MM - fixed width, NumberPrinterParser and called through appendValue()
        - dd - fixed width, NumberPrinterParser and called through appendValue()

        Note that "MMddyyyy" does not work, because the yyyy is at the end - the variable width element must come first.

        Thus, with this change, all the uses of WeekBasedFieldPrinterParser should be added via appendValue().

        What role the element actually takes in adjacent value parsing is then determined by "if (pp.minWidth == pp.maxWidth && pp.signStyle == SignStyle.NOT_NEGATIVE)".

        If we do this, then patterns like "YYYYww", "YYYYwwe", "YYYYwwc" and "yyyyMMddwwce" should all work (with adjacent values) - which will need tests.
        Show
        scolebourne Stephen Colebourne added a comment - Adjacent value parsing is allowed to have one element at the start that is variable width. However all elements must be NumberPrinterParser called through appendValue(). For example, "yyyyMMdd": - yyyy - variable width, but is a NumberPrinterParser called through appendValue() - MM - fixed width, NumberPrinterParser and called through appendValue() - dd - fixed width, NumberPrinterParser and called through appendValue() Note that "MMddyyyy" does not work, because the yyyy is at the end - the variable width element must come first. Thus, with this change, all the uses of WeekBasedFieldPrinterParser should be added via appendValue(). What role the element actually takes in adjacent value parsing is then determined by "if (pp.minWidth == pp.maxWidth && pp.signStyle == SignStyle.NOT_NEGATIVE)". If we do this, then patterns like "YYYYww", "YYYYwwe", "YYYYwwc" and "yyyyMMddwwce" should all work (with adjacent values) - which will need tests.
        Hide
        ntv Nadeesh Tv added a comment -
        FC Extension Request:

        Justification:
         • Many users first interaction with parsing will be via the patterns. Most of the patterns in java.time.format.DateTimeFormatter
        support adjacentvalue parsing. However, patterns 'w' (week-of-year) and 'W' (week-of-month) currently do not support
        adjacent value parsing. We want to enhance these by supporting adjacentvalue parsing for 'w' and 'W'.

        Remaining work to be done:
         Development ongoing

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

        Change will be integrated (locally) by: 2016-07-09
        Show
        ntv Nadeesh Tv added a comment - FC Extension Request: Justification:  • Many users first interaction with parsing will be via the patterns. Most of the patterns in java.time.format.DateTimeFormatter support adjacentvalue parsing. However, patterns 'w' (week-of-year) and 'W' (week-of-month) currently do not support adjacent value parsing. We want to enhance these by supporting adjacentvalue parsing for 'w' and 'W'. Remaining work to be done:  Development ongoing Compatibility Risk:   • Minimal (no existing tests will fail) Change will be integrated (locally) by: 2016-07-09
        Hide
        hgupdate HG Updates added a comment -
        URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bd9dd28d7b4f
        User: ntv
        Date: 2016-12-21 18:47:00 +0000
        Show
        hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bd9dd28d7b4f User: ntv Date: 2016-12-21 18:47:00 +0000
        Hide
        hgupdate HG Updates added a comment -
        URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/bd9dd28d7b4f
        User: lana
        Date: 2017-01-04 20:58:34 +0000
        Show
        hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/bd9dd28d7b4f User: lana Date: 2017-01-04 20:58:34 +0000

          People

          • Assignee:
            ntv Nadeesh Tv
            Reporter:
            webbuggrp Webbug Group
          • Votes:
            0 Vote for this issue
            Watchers:
            11 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved: