| 47d16f8116a013db8e7f3c5ebea3a2f25582fa77 |
|
19-Mar-2015 |
Fredrik Roubert <roubert@google.com> |
ICU55: Update locale data dependent test expectations.
ICU55 includes CLDR27 which has updated data for a number of locales,
which affects libcore tests.
(cherry picked from commit e6c88a51723b481276d21efcbcffe8f509488441)
Change-Id: I7e01ac1658c24b5b8c82e441ad3c3593f75ddefa
|
| 34cd02ceb324968e10114b365e5020f7a1bb89a5 |
|
26-Nov-2014 |
Narayan Kamath <narayan@google.com> |
Track date format changes for es_ES and es_US.
bug: 18478959
(cherry picked from commit b475aa04a19ad981dc5c459d735b1161fc20840f)
Change-Id: I885667063f735262e59070bb72a2bef7da021a02
|
| 8125fcd4a257f1370fafe0c289c30923011383ed |
|
29-Sep-2015 |
Fredrik Roubert <roubert@google.com> |
ICU 56: Update locale data dependent test expectations.
ICU 56 includes CLDR 28 which has updated data for a number of locales,
which affects libcore tests.
Change-Id: Idbc70a96f2e0535d989fcbd9a3b204f75e70b159
|
| 45190381fe84506d16b72daa64aa8160952068ea |
|
12-May-2015 |
Travis Keep <rocketman@google.com> |
Fix bug in formatting intervals at month boundaries.
In formatting date intervals, we subtract one day from the end time
if it falls on midnight the next day so that both times are in the
same day, thereby avoiding the date appearing in the formatted
interval. We did this by calling endCalendar.roll(Calendar.DAY_OF_MONTH, false).
However, if endCalendar was 1 May 2015 (say), the date rolls over
to 31 May 2015 (this is the documented behaviour of roll).
We now use endCalendar.add(Calendar.DAY_OF_MONTH, -1) which always
subtracts a day so that 1 May 2015 becomes 30 April 2015, this is
the desired behavior.
bug: 20708022
(cherry picked from commit 13faecd3105c23f8a60ce3a5847056489fd2d037)
Change-Id: Ic947c7c65008d23d1cb1b9bde6af35972ac6acd7
|
| e35062069f0ab8fc45954239127199b99e8b954c |
|
05-May-2015 |
Narayan Kamath <narayan@google.com> |
Add a test for bug 20708022.
Check that we correctly format date ranges that end at 00:00 on
the first day of a month.
bug: 20708022.
(cherry picked from commit 61dd198b79cd5c63fd8f18f7096b0f44b1491cd5)
Change-Id: Ia6387ac560024115314fd3fee2669c6cc11020a7
|
| 13faecd3105c23f8a60ce3a5847056489fd2d037 |
|
12-May-2015 |
Travis Keep <rocketman@google.com> |
Fix bug in formatting intervals at month boundaries.
In formatting date intervals, we subtract one day from the end time
if it falls on midnight the next day so that both times are in the
same day, thereby avoiding the date appearing in the formatted
interval. We did this by calling endCalendar.roll(Calendar.DAY_OF_MONTH, false).
However, if endCalendar was 1 May 2015 (say), the date rolls over
to 31 May 2015 (this is the documented behaviour of roll).
We now use endCalendar.add(Calendar.DAY_OF_MONTH, -1) which always
subtracts a day so that 1 May 2015 becomes 30 April 2015, this is
the desired behavior.
bug: 20708022
Change-Id: Id222582b26170a91a4ce2f4b5ebef3c15bce7c92
|
| 61dd198b79cd5c63fd8f18f7096b0f44b1491cd5 |
|
05-May-2015 |
Narayan Kamath <narayan@google.com> |
Add a test for bug 20708022.
Check that we correctly format date ranges that end at 00:00 on
the first day of a month.
bug: 20708022.
Change-Id: I8fd7cc9f1d130b7124f63fad09c0fda6ca4bb248
|
| 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
|
| 12fbbc16959d078dde23b3b15c8d3d127ef33507 |
|
15-Apr-2015 |
Neil Fuller <nfuller@google.com> |
Use ICU4J more in DateIntervalFormat and RelativeDateTimeFormatter
General strategy: Switch to ICU classes for Calendar, and generally
use ICU classes earlier to avoid multiple creations.
This also incorporates some feedback from narayan@ from
https://android-review.googlesource.com/#/c/145662/
Some small optimizations applied but the goal was not to make it
much faster, just to confirm it wasn't much slower. It has sped up
some methods, and slowed down others, but not much difference in
absolute terms.
All times in microseconds measured on a mako.
Original:
RelativeDateTimeFormatter_getRelativeDateTimeString 582.4
RelativeDateTimeFormatter_getRelativeDateTimeString_ABBREV 603.2
RelativeDateTimeFormatter_getRelativeTimeSpanString 39.9
RelativeDateTimeFormatter_getRelativeTimeSpanString_ABBREV 39.1
After:
RelativeDateTimeFormatter_getRelativeDateTimeString 207.2
RelativeDateTimeFormatter_getRelativeDateTimeString_ABBREV 218.2
RelativeDateTimeFormatter_getRelativeTimeSpanString 70.5
RelativeDateTimeFormatter_getRelativeTimeSpanString_ABBREV 67.4
Original:
DateIntervalFormat_formatDateRange_DATE 290
DateIntervalFormat_formatDateRange_DATE_TIME 298
DateIntervalFormat_formatDateRange_TIME 276
After:
DateIntervalFormat_formatDateRange_DATE 244
DateIntervalFormat_formatDateRange_DATE_TIME 256
DateIntervalFormat_formatDateRange_TIME 208
Change-Id: If043bd55ffec37ed2735aa1593f327b38749218c
|
| f7d3d845d1db889060262cfb7a9f73a2c4fdb7f3 |
|
07-Apr-2015 |
Travis Keep <rocketman@google.com> |
Switch DateIntervalFormat/RelativeDateTimeFormatter to ICU4J
Information below from the existing benchmarks on a hammerhead. All
times given in microseconds. Note that the new version is slower,
but this is a small difference in absolute terms and means less
maintenance for libcore.
The ICU team is rewriting some of the underlying code in ICU4J
for a future ICU release which may alter performance.
ICU4C + JNI
DateIntervalFormat_formatDateRange_DATE 67.8
DateIntervalFormat_formatDateRange_DATE_TIME 76.0
DateIntervalFormat_formatDateRange_TIME 54.8
ICU4J
DateIntervalFormat_formatDateRange_DATE 179
DateIntervalFormat_formatDateRange_DATE_TIME 181
DateIntervalFormat_formatDateRange_TIME 167
ICU4C + JNI
RelativeDateTimeFormatter_getRelativeDateTimeString 151.6
RelativeDateTimeFormatter_getRelativeDateTimeString_ABBREV 169.0
RelativeDateTimeFormatter_getRelativeTimeSpanString 27.8
RelativeDateTimeFormatter_getRelativeTimeSpanString_ABBREV 27.7
ICU4J
RelativeDateTimeFormatter_getRelativeDateTimeString 366.5
RelativeDateTimeFormatter_getRelativeDateTimeString_ABBREV 377.6
RelativeDateTimeFormatter_getRelativeTimeSpanString 23.2
RelativeDateTimeFormatter_getRelativeTimeSpanString_ABBREV 22.9
Bug: 20127691
Change-Id: I1ebc08fd9c974743026ae1e6c848fb4de8aa0e48
|
| e6c88a51723b481276d21efcbcffe8f509488441 |
|
19-Mar-2015 |
Fredrik Roubert <roubert@google.com> |
ICU55: Update locale data dependent test expectations.
ICU55 includes CLDR27 which has updated data for a number of locales,
which affects libcore tests.
Change-Id: I47c508a74945310dd7ad7abbb1dab1b77186a4e1
|
| b475aa04a19ad981dc5c459d735b1161fc20840f |
|
26-Nov-2014 |
Narayan Kamath <narayan@google.com> |
Track date format changes for es_ES and es_US.
bug: 18478959
Change-Id: Ie240bd0254f3aa3e5c75464393e73ff7067a91ac
|
| b8bd4697c6eb53584cbbeb5a443337ba7d62c9b5 |
|
08-Oct-2014 |
Elliott Hughes <enh@google.com> |
Unit test for bug 13234532.
Bug: 13234532
Change-Id: Ib57996d77f89c978926f4f20a9845e89914b63d8
|
| fda7c027e360292edfa4d32fadd2844efaa5f9d7 |
|
26-Jun-2014 |
Elliott Hughes <enh@google.com> |
Fix a faulty Julian day computation.
The use of Calendar.MILLISECONDS was wrong, as was the use of
ZONE_OFFSET without DST_OFFSET. The existing code pretty much
only works for the values tested in the unit test! This patch
adds new tests to make up for that.
I've also added calls to Calendar.clear to ensure we're not
leaking SECONDS and MILLISECONDS from the Calendar instances (which
get initialized to the current wall clock) into our test values.
This hasn't mattered in the past, but actually does matter here
because tests like isMidnight measure down to the millisecond.
Bug: https://code.google.com/p/android/issues/detail?id=72356
Signed-off-by: jasper tsai <jasper3_tsai@asus.com>
Signed-off-by: hellena shih <hellena_shih@asus.com>
Change-Id: I7d57590a95d3f026bdf1b991e0b1ddb47ba9af37
|
| 9b24ebf95f897a75c60c9c68d00694406afa6fbc |
|
20-Dec-2013 |
Elliott Hughes <enh@google.com> |
Test that icu4c only uses the Gregorian calendar when formatting date ranges for us.
(cherry picked from commit 6adedf966a3c9f5ae0118053c90bf67d870aa221)
Bug: 12004664
Change-Id: I89998748bf5724d5e13d6b31b9bbd55b1875fa28
|
| 1e768ec282dcc1a5f85a2e78852f7549802e5ccf |
|
27-Feb-2014 |
ccornelius <ccornelius@google.com> |
Update tests for to handle changes in ICU52.
Mostly changes are data related. These resolve most new issues
found with the update to external/icu4c version 52.
The only exceptions are
- a regression in arabic number parsing (see issue 13410257)
- a regression in bucket labeling for japanese characters (13434905)
Change-Id: I7f865c64556bd0492b67dc6c81b50387a5c19617
|
| 6adedf966a3c9f5ae0118053c90bf67d870aa221 |
|
20-Dec-2013 |
Elliott Hughes <enh@google.com> |
Test that icu4c only uses the Gregorian calendar when formatting date ranges for us.
Bug: 12004664
Change-Id: Ia77d55e525c0d10741df7660db598d85b7d4a0a9
|
| 4409dd652330c8eaaa32eec36ce1600aeeea1464 |
|
13-Nov-2013 |
Elliott Hughes <enh@google.com> |
Fix flakiness in DateIntervalFormatTest.
Bug: https://code.google.com/p/android/issues/detail?id=62139
(cherry picked from commit 205d7f16d2d6a302c401f39a905dc2a05c1f271b)
Change-Id: I841f7fc38132213031c3092fe9309c8d6ad70acf
|
| 205d7f16d2d6a302c401f39a905dc2a05c1f271b |
|
13-Nov-2013 |
Elliott Hughes <enh@google.com> |
Fix flakiness in DateIntervalFormatTest.
Bug: https://code.google.com/p/android/issues/detail?id=62139
Change-Id: I3e1f5d64e432b1fa7b701ba285ffcb73ca81cc6c
|
| 033bcc2bf261398a972845396e3a2f0c2c847772 |
|
10-Sep-2013 |
Elliott Hughes <enh@google.com> |
Add a regression test for an already-fixed formatDateRange bug.
Bug: 8467515
Change-Id: I37fe971c1136301d2cc29bd6bc321133dbe50f5e
|
| 41a439b85b660a1c7cb33b1ae0e4b3e5713664f1 |
|
07-Sep-2013 |
Elliott Hughes <enh@google.com> |
Fix formatDateRange's decisions about when to show a year.
Bug: 10209343
(cherry picked from commit e1a17472940f90d6712203f3523bb054bdbfd6e4)
Change-Id: I9931c3e72d5623dec8cc21c09eae5532aa7eb7f6
|
| e1a17472940f90d6712203f3523bb054bdbfd6e4 |
|
07-Sep-2013 |
Elliott Hughes <enh@google.com> |
Fix formatDateRange's decisions about when to show a year.
Bug: 10209343
Change-Id: Id386e9ee4acf46ce3b4d0802b4aca49a0b0667cb
|
| bb0a7318f2ca1bc9768d6d68b9a4521dd40f09a9 |
|
06-Sep-2013 |
Elliott Hughes <enh@google.com> |
Fix formatDateRange's handling of all-day events.
Android's formatDateRange's interpretation of a time span running until 0 ms
into a day is different from icu4c. Traditionally we didn't count that as
being the next day, but icu4c does.
Bug: 10560853
(cherry picked from commit e6d0a351d58747ca6958ee9c9a12d2c3feb7f9db)
Change-Id: Ia394fe541afcfccfe801a8aa704ad8d14212d817
|
| e6d0a351d58747ca6958ee9c9a12d2c3feb7f9db |
|
06-Sep-2013 |
Elliott Hughes <enh@google.com> |
Fix formatDateRange's handling of all-day events.
Android's formatDateRange's interpretation of a time span running until 0 ms
into a day is different from icu4c. Traditionally we didn't count that as
being the next day, but icu4c does.
Bug: 10560853
Change-Id: I99fbbf19ad98147c9c4ff568231aec71d97a8938
|
| e8f98b22cbd859c5c2cad9866335128a95adcd81 |
|
04-Sep-2013 |
Elliott Hughes <enh@google.com> |
Don't abbreviate 24-hour times.
Bug: 10318326
(cherry picked from commit 504a9b9d616bd108d26077d6d215677a29605f22)
Change-Id: I3ea76ad516b7d76b7e56a562b56cdfeff451f289
|
| 504a9b9d616bd108d26077d6d215677a29605f22 |
|
04-Sep-2013 |
Elliott Hughes <enh@google.com> |
Don't abbreviate 24-hour times.
Bug: 10318326
Change-Id: Ifbd50a994e30ce11e060eebd0bf6b8f428c1264d
|
| e9852a18ca0343b27096c72d31bbba839ca6aaf0 |
|
01-Aug-2013 |
Elliott Hughes <enh@google.com> |
Merge "Fix DateIntervalFormat to take time zone into account."
|
| 507e7789a5aace0f30d85dab8862151b1eba693a |
|
01-Aug-2013 |
Elliott Hughes <enh@google.com> |
Fix DateIntervalFormat to take time zone into account.
Bug: 10089890
Change-Id: I91e61429108abb16810701d6d9feb6d1ad431740
|
| 480537d9d51add98bffe6d9a9ef3b1022b959336 |
|
03-May-2013 |
Elliott Hughes <enh@google.com> |
Add an icu4c-based DateIntervalFormat.
This will be used to replace DateUtils.formatDateRange's implementation.
Bug: 7289514
Change-Id: I5588c79a9d0a5cbed3b4600389c545e83fc26967
|