| 07349e9d1011192699a08e7a0553b3e0e88da103 |
|
29-Jul-2014 |
Neil Fuller <nfuller@google.com> |
Change the DateFormatSymbols serialized form
Adding locale to the serialized form of
DateFormatSymbols.
Some duplicated code around the generation of
numeric / offset timezone strings (e.g. GMT+08:00) has
been removed. A new hidden method has been added
to TimeZone to create this string.
The timezone string lookup has been moved into
LocaleData and it now has a single path rather
than treating the customZoneStrings path as special.
customZoneStrings has been removed from
DateFormatSymbols because it would potentially
have an incorrect value after serialization and
it is no longer required.
(cherry picked from commit f39e1d71b478bafac028043a59683dfbed1d9df0)
Bug: 16502916
Change-Id: Id5b18728dc5cd0656d77d67eb509beedcc52f893
|
| f39e1d71b478bafac028043a59683dfbed1d9df0 |
|
29-Jul-2014 |
Neil Fuller <nfuller@google.com> |
Change the DateFormatSymbols serialized form
Adding locale to the serialized form of
DateFormatSymbols.
Some duplicated code around the generation of
numeric / offset timezone strings (e.g. GMT+08:00) has
been removed. A new hidden method has been added
to TimeZone to create this string.
The timezone string lookup has been moved into
LocaleData and it now has a single path rather
than treating the customZoneStrings path as special.
customZoneStrings has been removed from
DateFormatSymbols because it would potentially
have an incorrect value after serialization and
it is no longer required.
Bug: 16502916
Change-Id: I2b317e34ba4772beb372a75dd08c95113408b9cc
|
| df624c1cc36dc17e4051d1100a3400aeb4252511 |
|
25-Jun-2014 |
Narayan Kamath <narayan@google.com> |
Fix handling of invalid locales in Date/DecimalFormatSymbols.
For locales whose language code is "und" we use Locale.ROOT
instead. This also fixes two other corner cases :
- We were using the wrong locale to fetch timezone strings
when the input locale was null. we now use the same locale
throughout by making sure we don't perform any subsititutions
in LocaleData.get.
- Adds a clearer comment about the broken serialization
behaviour.
bug: 15849709
(cherry picked from commit 043a1424a4e3bbb5abc9d9e11c9c088b20f4ca7d)
Change-Id: I716fb421fb8643dedebb3a7797a76ed1dd86c548
|
| 5c0472fd7c53464e526bb833707551d85dbafec1 |
|
25-Jun-2014 |
Narayan Kamath <narayan@google.com> |
Fix handling of invalid locales in Date/DecimalFormatSymbols.
For locales whose language code is "und" we use Locale.ROOT
instead. This also fixes two other corner cases :
- We were using the wrong locale to fetch timezone strings
when the input locale was null. we now use the same locale
throughout by making sure we don't perform any subsititutions
in LocaleData.get.
- Adds a clearer comment about the broken serialization
behaviour.
bug: 15849709
Change-Id: I95e7eb0ccb7458711038ce9b1c76b3279acda9d6
|
| 74473971cc9d960376295fbcc430320c9ed62991 |
|
29-Aug-2013 |
Elliott Hughes <enh@google.com> |
Fix harmony java.text test failures.
There were plenty of bad tests here, but there were some real bugs too.
* DecimalFormat was only handling RoundingMode.UNNECESSARY for double
formatting.
* DecimalFormat was not ensuring that it's superclass' fields were
being correctly updated.
* NumberFormat was throwing NPE for a null object because of an
improved detail message, despite being specified to throw IAE.
* We weren't mapping NumberFormat.Field instances to the corresponding icu4c
UNUM_x_FIELD constant, so we weren't actually setting FieldPosition
objects correctly.
* SimpleDateFormat was not formatting milliseconds correctly with 'S'.
* NativeDecimalFormat wasn't handling JNI NewString OOME correctly.
Bug: 2528220
Bug: 3056865
Bug: 3057080
Bug: 3057090
Change-Id: Iac11f902f2e9649e596e7e7b7bc501b13e956fca
|
| 994e4e5ded616a100ca42b16cffa36aa9f595f64 |
|
28-Aug-2013 |
Elliott Hughes <enh@google.com> |
Add harmony java.text tests.
Change-Id: Id8d0acd77d08ff337b4851ae74a48cc002d66cd9
|