| 9ecf6aa75b0a62df06e66e3c6a7e12f802b8c89d |
|
27-Feb-2018 |
Pete Gillin <peteg@google.com> |
Fix midnight-to-next-midnight bug in DateIntervalFormat.
There is special handling in DateIntervalFormat.formatDateRange for
ranges which end at midnight. When showing times, and the end-point is
midnight of the day following the start-point, it suppresses the end
date so that it shows e.g. "February 27, 04:00 - 00:00" instead of
"February 27, 04:00 - February 28, 00:00". This behaviour is broken
when the start date is also midnight, we need the dates there to
disambiguate (rather than creating an empty range). This change
addresses that, while preserving all other behaviours.
Tests are added to cover various aspects of this special casing. The
second of the four assertions added fails without this change.
Bug: 68847519
Test: cts-tradefed run cts-dev -m CtsLibcoreTestCases
Test: cts-tradefed run cts-dev -m CtsTextTestCases -t android.text.format.cts.DateUtilsTest
Change-Id: I7d109af69e1962163b74c5837fd782156765fbe2
|
| 728029941ba340aeb8e4098b7ad12d3a30e38aa9 |
|
05-Oct-2015 |
Neil Fuller <nfuller@google.com> |
Switch from jarjar to generated source for ICU4J
Future changes will include ICU4J classes as public APIs
(still beneath android.icu). To generate these docs source
code will be needed under the expected package (android.icu),
as well as the ability to apply changes to the javadoc
comments programatically so ICU can be upgraded easily.
A consequence of this change is that libcore code can now
depend on icu in the android.icu package and not the
com.ibm.icu package as was the case previously. A nice
side effect is that the source code is available for use
during debugging as well.
Bug: 22023363
Change-Id: Icba5668fae53e2dc98ccc74e2f1ad1ca226e5feb
|
| a40d2447b6f516116135ee7f126579771ba98a2c |
|
17-Apr-2015 |
Neil Fuller <nfuller@google.com> |
Ensure consistency of capitalization in RelativeDateTimeFormatter
Contains refactoring. Benchmarks below to show no appreciable
negative performance impact to formatters. We do now cache a new
type of formatter.
Benchmarks measured in microseconds on mako.
Before:
DateIntervalFormat_formatDateRange_DATE 244
DateIntervalFormat_formatDateRange_DATE_TIME 256
DateIntervalFormat_formatDateRange_TIME 208
RelativeDateTimeFormatter_getRelativeDateTimeString 207.2
RelativeDateTimeFormatter_getRelativeDateTimeString_ABBREV 218.2
RelativeDateTimeFormatter_getRelativeTimeSpanString 70.5
RelativeDateTimeFormatter_getRelativeTimeSpanString_ABBREV 67.4
After:
DateIntervalFormat_formatDateRange_DATE 237
DateIntervalFormat_formatDateRange_DATE_TIME 241
DateIntervalFormat_formatDateRange_TIME 200
RelativeDateTimeFormatter_getRelativeDateTimeString 149.4
RelativeDateTimeFormatter_getRelativeDateTimeString_ABBREV 161.8
RelativeDateTimeFormatter_getRelativeTimeSpanString 71.7
RelativeDateTimeFormatter_getRelativeTimeSpanString_ABBREV 69.0
Bug: 20247811
Change-Id: I51075f89ca6b1d8862335e0e5a4d67a5624edfa6
|