Skip to content

GitLab

Switch branch/tag
  1. 29 May, 2014 1 commit
  3. 21 May, 2014 9 commits
  5. 20 May, 2014 12 commits
  7. 19 May, 2014 5 commits
  9. 18 May, 2014 1 commit
  11. 17 May, 2014 1 commit
  13. 16 May, 2014 3 commits
  15. 15 May, 2014 6 commits
  17. 14 May, 2014 2 commits
    • Neil Fuller's avatar
      Fix a test that assumes Locale.getDefault() == Locale.US · 9e880cc0
      Neil Fuller authored 
      If the device is set to non-English locale this fails.
Setting the default locale explicitly makes the tests clearer
(the CtsTestRunner / vogar) sets it back again.

Change-Id: I4c197f4823115f178acc51a62a64855b790011b4
      9e880cc0
    • Neil Fuller's avatar
      Removing data hacks from ICU root.txt · e4a3071d
      Neil Fuller authored 
      Previously, the upstream ICU data was modified
to support special short codes (e.g. PST, CET) so that
they were recognized when parsing/formatting in all
locales with SimpleDateFormat.parse()/format().

In an effort to more-closely replicate ICU this change
does *not* introduce special casing for short /
abbreviated names from Java APIs.

This may have impact for applications that use
Date.toString() (but not Date.parse()),
SimpleDateFormat.parse(), SimpleDateFormat.format(),
and anything that uses TimeZone methods that deal in
formatting and zone strings (e.g. getZoneStrings(),
getDisplayName()).

Details:

Date.parse() is unaffected because it handles abbreviated
names only, is not internationalized and contains a set
of recognized strings. Date.toString() is affected because
it relies on SimpleDateFormat for formatting.

ICU still supports abbreviated / short names for
locales where those terms are considered unambiguous for
residents of that locale. For example, "PST" is still parsed /
formatted in Locale.US when using SimpleDateFormat.
However, with this change "PST" will not be parsed/formatted
other locales such as Locale.FRANCE, Locale.UK.

If SimpleDateFormat.format() / TimeZone.getDisplayName() cannot
find a short / abbreviated name for a timezone in the
specified/defaulted locale, then a GMT offset is output as per
the docs.

Of particular note are methods that rely on Locale.getDefault()
and/or Locale.getTimeZone(). Most user-facing usecases are
expected to be unaffected. For example, US users will continue
to see / enter PST. Applications that were previously
parsing a date string containing (for example) PST but relying
on the default locale will start seeing failures.

Most of the changes are in tests that were hardcoding
expected strings or relying on the default locale.

This change is associated with a change in external/icu4c:
I04acd15c62d49c0cf30cc63f60db320bdb8e22e9

This commit also includes minor test changes related to
parsing/formatting dates where the default device locale
is assumed to be US (or other English-speaking locale).
Date-related tests that were relying  on the default locale
and broke when it was set to a non-English script are now
explicitly setting it.

Note: The tests all rely on the CtsTestRunner / Vogar
resetting the default Locale / TimeZone between each test.

Bug: 11413756
Change-Id: I9ae6397cf5335ef325aedb6472d0d66a6127e1dd
      e4a3071d