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

        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'?
        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.)
        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
        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

          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: