diff options
author | Joachim Sauer <jsauer@google.com> | 2016-07-15 13:15:33 +0100 |
---|---|---|
committer | Joachim Sauer <jsauer@google.com> | 2016-09-29 17:26:12 +0100 |
commit | 4947038a7acb466855746df19d41ef26be507aa4 (patch) | |
tree | 477a95f47b36ab2b566019e3423f43cafa6245d7 /annotations/generate_annotated_java_files.py | |
parent | fc4fa476a9292ae6a512803390e0ce6af6e8e4a9 (diff) |
Delegate time zone names handling to ICU in SDF.
Delegate parsing and formatting time zone names to the relevant ICU code
(android.icu.text.TimeZoneNames).
This fixes an issue where the cache of time zone names was time dependent.
The old code that uses DateFormatSymbols.getZoneStrings() for parsing
and formatting is still used as a fallback, but it's only used if the
DateFormatSymbols.setZoneStrings() has been called explicitly.
Performance of this code is between ~40-105% of the old code, depending
on the exact use case (Measured with SimpleDateFormatBenchmark, times in
ns per iteration on a bullhead, with cpu frequencies locked to 864000):
Before After
time_createAndParseWithTimeZoneLong 105,195 172,892
time_createAndParseWithTimeZoneShort 96,313 189,077
time_createFormatWithTimeZone 26,551 25,351
time_formatWithTimeZoneLong 10,700 13,151
time_formatWithTimeZoneShort 10,872 13,352
time_parseWithTimeZoneLong 57,348 101,426
time_parseWithTimeZoneShort 48,323 114,452
time_parseWithoutTimeZone 15,293 16,128
This change slightly affects how time zone names are parsed and
formatted:
* When formatting a date, we now use time zone name information that is
accurate for the time we format. Previously we implicitly used the time
at which the time zone name data was cached (which happened to be
whatever the RTC was at boot time for the root, US and default locale).
While this may result in differences in how past dates are formatted
(specifically when formatting a date that is before the last time a time
zone name changed), the new behaviour is definitely more correct than the
old one.
* When parsing a date, we now use the time zone name information that is
accurate at time the parse happens (according to the RTC). This means that
some older dates might not round-trip correctly (because the zone name
information used for parsing and formatting is different). Previously we
used the same time as for formatting (i.e. some arbitrary time when the
zone names were cached).
Test: libcore/run-libcore-tests libcore.java.text org.apache.harmony.tests.java.text
Bug: 20879084
Change-Id: Id9f70acad60d97b9879df14b5b5de6e89b209de3
Diffstat (limited to 'annotations/generate_annotated_java_files.py')
0 files changed, 0 insertions, 0 deletions