summaryrefslogtreecommitdiff
path: root/annotations/generate_annotated_java_files.py
diff options
context:
space:
mode:
authorJoachim Sauer <jsauer@google.com>2016-07-15 13:15:33 +0100
committerJoachim Sauer <jsauer@google.com>2016-09-29 17:26:12 +0100
commit4947038a7acb466855746df19d41ef26be507aa4 (patch)
tree477a95f47b36ab2b566019e3423f43cafa6245d7 /annotations/generate_annotated_java_files.py
parentfc4fa476a9292ae6a512803390e0ce6af6e8e4a9 (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