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

Add date-time patterns 'v' and 'vvvv'

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b119

      Description

      Issue https://bugs.openjdk.java.net/browse/JDK-8154567 indicates that the JDK has the necessary data for the "generic non-location" format of time-zones. (See http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-dates.html#Using_Time_Zone_Names for terminology)

      Pattern letters "v" and "vvvv" defined by CLDR output this format. As such, since the data is available, the pattern letters should be added. See http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-dates.html#Date_Format_Patterns

        Activity

        scolebourne Stephen Colebourne created issue -
        ntv Nadeesh Tv (Inactive) made changes -
        Field Original Value New Value
        Assignee Nadeesh Tv [ ntv ]
        Hide
        ntv Nadeesh Tv (Inactive) added a comment -
        Currently DateFormatterBuilder::appendPattern support only
        VV 2 appendZoneId()

        But according to spec http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-dates.html#Date_Format_Patterns
        it can be
        V 1..4
        My concern with pattern 'V' (CAPITAL ) is, it's used as fall back for 'v' (SMALL)
        v 1 or 4 -- When generic non-location format is unavailable, falls back to the generic location format ("VVVV").

        Is not the data available for other pattern of "V"? If yes, then what should do in the fall back cases of 'v'?
        Show
        ntv Nadeesh Tv (Inactive) added a comment - Currently DateFormatterBuilder::appendPattern support only VV 2 appendZoneId() But according to spec http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-dates.html#Date_Format_Patterns it can be V 1..4 My concern with pattern 'V' (CAPITAL ) is, it's used as fall back for 'v' (SMALL) v 1 or 4 -- When generic non-location format is unavailable, falls back to the generic location format ("VVVV"). Is not the data available for other pattern of "V"? If yes, then what should do in the fall back cases of 'v'?
        ntv Nadeesh Tv (Inactive) made changes -
        Status New [ 10000 ] Open [ 1 ]
        Hide
        scolebourne Stephen Colebourne added a comment -
        We will need some fallback if the "generic non-location" data is not available, but I am not concerned if the fallback is not exactly as defined in CLDR (because we don't have the data).

        Our current behaviour in ZoneTextPrinterParser appears to be to fallback to the ZoneId. CLDR would suggest fallback to use LocalizedOffsetIdPrinterParser. For now, we should be consistent with current ZoneTextPrinterParser behaviour and fallback to the ZoneId.

        (The spec for these fields is generally written in such a way that it is fine for details of the data to change in later releases. So, if Java adds text data for the "generic location format" in the future, we can change the falback at that point.)
        Show
        scolebourne Stephen Colebourne added a comment - We will need some fallback if the "generic non-location" data is not available, but I am not concerned if the fallback is not exactly as defined in CLDR (because we don't have the data). Our current behaviour in ZoneTextPrinterParser appears to be to fallback to the ZoneId. CLDR would suggest fallback to use LocalizedOffsetIdPrinterParser. For now, we should be consistent with current ZoneTextPrinterParser behaviour and fallback to the ZoneId. (The spec for these fields is generally written in such a way that it is fine for details of the data to change in later releases. So, if Java adds text data for the "generic location format" in the future, we can change the falback at that point.)
        ntv Nadeesh Tv (Inactive) made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Understanding Fix Understood [ 10001 ]
        Show
        ntv Nadeesh Tv (Inactive) added a comment - http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040924.html
        Hide
        hgupdate HG Updates added a comment -
        URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/48148c98c95a
        User: ntv
        Date: 2016-05-13 18:58:46 +0000
        Show
        hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/48148c98c95a User: ntv Date: 2016-05-13 18:58:46 +0000
        hgupdate HG Updates made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Resolved In Build team [ 17324 ]
        Understanding Fix Understood [ 10001 ]
        Fix Version/s 9 [ 14949 ]
        Resolution Fixed [ 1 ]
        Hide
        hgupdate HG Updates added a comment -
        URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/48148c98c95a
        User: lana
        Date: 2016-05-18 20:42:24 +0000
        Show
        hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/48148c98c95a User: lana Date: 2016-05-18 20:42:24 +0000
        hgupdate HG Updates made changes -
        Resolved In Build team [ 17324 ] master [ 18256 ]
        hgupdate HG Updates made changes -
        Resolved In Build master [ 18256 ] b119 [ 17310 ]
        aroy Abhijit Roy made changes -
        Link This issue duplicates JDK-8172165 [ JDK-8172165 ]
        iris Iris Clark made changes -
        Labels jsr379-annex2-tbd
        aroy Abhijit Roy made changes -
        Link This issue duplicates JDK-8172165 [ JDK-8172165 ]
        iris Iris Clark made changes -
        Labels jsr379-annex2-tbd jsr379-annex1
        darcy Joe Darcy made changes -
        Link This issue csr of CCC-8155823 [ CCC-8155823 ]

          People

          • Assignee:
            ntv Nadeesh Tv (Inactive)
            Reporter:
            scolebourne Stephen Colebourne
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: