| 43024a7ede44d5043e060749fe87c54c727014f2 |
|
23-Mar-2016 |
Neil Fuller <nfuller@google.com> |
Comment assertion related to harmony behavior
This line was supposed to be commented by commit
1a01a6513ffe17389a1f32d4416166741a6973a4
Bug: 27158550
Change-Id: Id78bd571f97e3ca18506d14a9a3a0cadfa5f273c
|
| 2cbcbf0677be8ec53adbc27cd4c949892ccfc046 |
|
23-Mar-2016 |
Neil Fuller <nfuller@google.com> |
Comment assertion related to harmony behavior
This line was supposed to be commented by commit
1a01a6513ffe17389a1f32d4416166741a6973a4
Bug: 27158550
Change-Id: Id78bd571f97e3ca18506d14a9a3a0cadfa5f273c
|
| b829e3450e1120aef42fce2c9d09add49286552d |
|
21-Mar-2016 |
Neil Fuller <nfuller@google.com> |
Fix CTS tests broken by the switch to OpenJDK code
This commit includes a refactoring to avoids relying on the same
DateFormat instance when parsing multiple strings.
Due to bug 27760434 the Android SimpleDateFormat does not currently
reset the calendar timezone after a parse() which
can cause test state to leak from one test to another. Explicitly
creating / providing a new SimpleDateFormat instance to use for
parsing and formatting also makes the tests clearer.
Two actual fixes:
1) Explicitly creating a new format in assertParse() fixes
test_parseLjava_lang_StringLjava_text_ParsePosition, which used
to work because the timezone was reset after a parse. Bug 27760434
has been created to follow up and potentially revert the
SimpleDateFormat to the old Android behavior.
2) test_parse_W_w_dd_MMMM_yyyy_EEEE no longer tests that parsing
"3 12 10 March 2002 Monday" results in the expected date. The
pattern includes multiple indicators of day and month and the
resulting Date is an indication of the internal implementation more
than a meaningful result. There are numerous other tests that
involve similar patterns but only this one actually broke.
Bug: 26023857
Bug: 27158550
Bug: 27760434
Change-Id: Id7829c4c6930d008d2dfcb978e4f0bc29f49dbf7
|
| 1a01a6513ffe17389a1f32d4416166741a6973a4 |
|
21-Mar-2016 |
Neil Fuller <nfuller@google.com> |
Fix CTS tests broken by the switch to OpenJDK code
This commit includes a refactoring to avoids relying on the same
DateFormat instance when parsing multiple strings.
Due to bug 27760434 the Android SimpleDateFormat does not currently
reset the calendar timezone after a parse() which
can cause test state to leak from one test to another. Explicitly
creating / providing a new SimpleDateFormat instance to use for
parsing and formatting also makes the tests clearer.
Two actual fixes:
1) Explicitly creating a new format in assertParse() fixes
test_parseLjava_lang_StringLjava_text_ParsePosition, which used
to work because the timezone was reset after a parse. Bug 27760434
has been created to follow up and potentially revert the
SimpleDateFormat to the old Android behavior.
2) test_parse_W_w_dd_MMMM_yyyy_EEEE no longer tests that parsing
"3 12 10 March 2002 Monday" results in the expected date. The
pattern includes multiple indicators of day and month and the
resulting Date is an indication of the internal implementation more
than a meaningful result. There are numerous other tests that
involve similar patterns but only this one actually broke.
Bug: 26023857
Bug: 27158550
Bug: 27760434
Change-Id: Id7829c4c6930d008d2dfcb978e4f0bc29f49dbf7
|
| 6557ca8f65418ae09ee1e0d3b23e9e55d2ee90ff |
|
15-Feb-2016 |
Narayan Kamath <narayan@google.com> |
SimpleDateFormat: Amend tests to match specified behaviour.
We don't claim to support numeric timezones of the form GMT+hh
or GMT+h:m. This worked purely by accident in earlier releases of
Android and we don't want applications relying on this behaviour.
bug: 27158550
Change-Id: I5e151cc4dd7a339d606d9d0ec51d700bad4b5506
|
| ce6a6ab0b88edf5be2df1105fe0c0831675f695b |
|
15-Feb-2016 |
Narayan Kamath <narayan@google.com> |
SimpleDateFormatTest: Fix a couple of bogus tests involving non-olson tzs.
The string 0001 should be treated as a minute offset, not an hour.
bug: 27158550
Change-Id: If151fc0e3a6a17e3bf4f14223d39c379d98ad4c9
|
| 320cf5e4b7dfceb8c727ddac762f63deaacd5d91 |
|
15-Feb-2016 |
Narayan Kamath <narayan@google.com> |
SimpleDateFormatTest : Remove dead code.
Only serves to confuse readers.
Change-Id: I96ae1c825c0a4aaf42410ba04532a929765e8d89
|
| 31594005b5b5dd6b9f06f4ed75bdf2a156984f75 |
|
05-Feb-2016 |
Paul Duffin <paulduffin@google.com> |
Revert "Revert "Split the harmony SimpleDateFormatTest test methods up""
The newly added but failing tests have been added to the
platform/art/tools/libcore_failures.txt file alongside the
test_parseLjava_lang_StringLjava_text_ParsePosition test so it is now safe to commit this, it won't break the build bot.
This reverts commit 52c6d227ced1a17fe7ea73aff3c6145dff80bb25.
Change-Id: I002ccbe4f54b2b345e33a767cd359f9371780a01
|
| 26924d36ce2a2dc97191bf8cc3c6d4c07736941e |
|
04-Feb-2016 |
Paul Duffin <paulduffin@google.com> |
Split the harmony SimpleDateFormatTest test methods up
Split the test_parseLjava_lang_StringLjava_text_ParsePosition
test method that is currently failing into smaller tests. That
should make it easier to isolate the problem and see which of
the many things tested in there are failing. This doesn't fix
any code but it does reveal that there are a number of
different tests failing.
As of this change the following tests are failing. That includes
the original test failure and some of the separate tests.
test_parseLjava_lang_StringLjava_text_ParsePosition
test_parse_W_w_dd_MMMM_yyyy_EEEE
test_parse_dayOfYearPatterns
test_parse_h_m_z
test_parse_h_z_2DigitOffsetFromGMT
test_parse_h_z_4DigitOffsetFromGMT
test_parse_h_z_4DigitOffsetNoGMT
Bug: 25998255
Change-Id: I0843f741eef7c3795d2e08f0139cba4ad8e1bd61
|
| 52c6d227ced1a17fe7ea73aff3c6145dff80bb25 |
|
04-Feb-2016 |
Nicolas Geoffray <ngeoffray@google.com> |
Revert "Split the harmony SimpleDateFormatTest test methods up"
Fails following tests:
org.apache.harmony.tests.java.text.SimpleDateFormatTest#test_parse_W_w_dd_MMMM_yyyy_EEEE (no test history available)
org.apache.harmony.tests.java.text.SimpleDateFormatTest#test_parse_dayOfYearPatterns (no test history available)
org.apache.harmony.tests.java.text.SimpleDateFormatTest#test_parse_h_m_z (no test history available)
org.apache.harmony.tests.java.text.SimpleDateFormatTest#test_parse_h_z_2DigitOffsetFromGMT (no test history available)
org.apache.harmony.tests.java.text.SimpleDateFormatTest#test_parse_h_z_4DigitOffsetFromGMT (no test history available)
org.apache.harmony.tests.java.text.SimpleDateFormatTest#test_parse_h_z_4DigitOffsetNoGMT (no test history available)
This reverts commit 06e77eddbb4e2c7799ac10c3378ae31399e37da8.
Change-Id: If71307a10d10b434bef3fed3187546555108b659
|
| 06e77eddbb4e2c7799ac10c3378ae31399e37da8 |
|
04-Feb-2016 |
Paul Duffin <paulduffin@google.com> |
Split the harmony SimpleDateFormatTest test methods up
Split the test_parseLjava_lang_StringLjava_text_ParsePosition
test method that is currently failing into smaller tests. That
should make it easier to isolate the problem and see which of
the many things tested in there are failing. This doesn't fix
any code but it does reveal that there are a number of
different tests failing.
As of this change the following tests are failing. That includes
the original test failure and some of the separate tests.
test_parseLjava_lang_StringLjava_text_ParsePosition
test_parse_W_w_dd_MMMM_yyyy_EEEE
test_parse_dayOfYearPatterns
test_parse_h_m_z
test_parse_h_z_2DigitOffsetFromGMT
test_parse_h_z_4DigitOffsetFromGMT
test_parse_h_z_4DigitOffsetNoGMT
Bug: 25998255
Change-Id: I0843f741eef7c3795d2e08f0139cba4ad8e1bd61
|
| ec34d4cb13af4d0b129f7ecb76dadbd3176e1897 |
|
30-Jul-2014 |
Neil Fuller <nfuller@google.com> |
Fix SimpleDateFormatTest when run outside California
If the device was set to a timezone besides America/Los_Angeles
the test would fail. Under cts-tradefed the SimpleDateFormat
was being created at class load time (using the device default)
and then the timezone default was being set to
America/Los_Angeles during setUp().
Contains refactoring to remove nested test case and
reformatting.
(cherry picked from commit a4b67b6f5ba9d233023c55c816121070770e4ac5)
Change-Id: I6bde5cd3459f94a9224b330e2d1e69ebecda6a4c
|
| a4b67b6f5ba9d233023c55c816121070770e4ac5 |
|
30-Jul-2014 |
Neil Fuller <nfuller@google.com> |
Fix SimpleDateFormatTest when run outside California
If the device was set to a timezone besides America/Los_Angeles
the test would fail. Under cts-tradefed the SimpleDateFormat
was being created at class load time (using the device default)
and then the timezone default was being set to
America/Los_Angeles during setUp().
Contains refactoring to remove nested test case and
reformatting.
Change-Id: I26a7a2c6ce0d6205cf6d20c9b4cbebf550da19ce
|
| 018b61546e6a69ff9c5105ec017c85df641766c4 |
|
10-Sep-2013 |
Elliott Hughes <enh@google.com> |
Fix a bug in DateFormat, clean up some SimpleDateFormat tests.
We failed a couple of tests because of an assumption about the default
time zone:
junit.framework.AssertionFailedError: Wrong format: " d" expected: 12 result: 11
at java.text.SimpleDateFormatTest.test(SimpleDateFormatTest.java:55)
at org.apache.harmony.tests.java.text.SimpleDateFormatTest.test_formatLjava_util_DateLjava_lang_StringBufferLjava_text_FieldPosition(SimpleDateFormatTest.java:347)
junit.framework.AssertionFailedError: Wrong result: h input: 12 expected: Thu Jan 01 00:00:00 UTC 1970 result: Thu Jan 01 08:00:00 UTC 1970
at java.text.SimpleDateFormatTest.parse(SimpleDateFormatTest.java:86)
at org.apache.harmony.tests.java.text.SimpleDateFormatTest.test_parseLjava_lang_StringLjava_text_ParsePosition(SimpleDateFormatTest.java:546)
Cleaning up the tests and merging OldSimpleDateFormatTest into
SimpleDateFormatTest accidentally made one of our tests more
strict, at which point it failed because we weren't updating the
FieldPosition for 'z' or 'Z' when formatting or parsing. So this
patch fixes that by mapping the DateFormat.Field to the appropriate
int for Calendar.
Change-Id: If4b2f2c02d8ccd50d96d77df3b60e1c1d65ae666
|
| 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
|