| 1e27cef4494019042dc77879fe27519ff2938d12 |
|
13-Feb-2017 |
Tobias Thierer <tobiast@google.com> |
Revert "Revert "java.time.Instant.toEpochMilli() fixes""
This reapplies commit ca2b1f0f50392f5a8e91a3d5513ea850ba4e686b.
The original commit was reverted. It had broken DateTest because
it changed the minimum/maximum Instant that is convertible to Date.
Those boundaries are undocumented; the old behavior was more
arbitrary and was never launched in Android. Therefore, it's
reasonable to just update the test.
This CL reapplies the original change and updates DateTest accordingly.
Test: DateTest
Test: CtsLibcoreTestCases
Bug: 31028374
Bug: 35245079
This reverts commit 18db57ad9257a1ba0451fa808294066e8f329287.
Change-Id: I8dd24ac6f0d0d5f58d2d0bb51404ba5c8ced2473
|
| 2485f0b24ad267fa1134dd84b3bb47d3cf9b8d21 |
|
06-Sep-2016 |
Tobias Thierer <tobiast@google.com> |
Update java.util.Date to OpenJDK8u60
Added two missing Android-changed comments.
Added upstream logic for converting to/from Instant
Added tests for conversion to/from Instant.
The minimum millisecond time (just under a second after
new Date(Long.MIN_VALUE)) that can be converted from
Instant to Date without encountering ArithmeticException
is not clearly documented. A test now ensures that this
boundary value remains consistent; no attempt was made
to change or explain the current boundary value.
Test: CtsLibcoreTestCases
Bug: 29935305
Change-Id: I79aff68ace5157cd3db5b1304651d07999d66796
|
| fa9818c081c1c0158d80ddd9b1f92990b3e0eb30 |
|
06-Jan-2016 |
Narayan Kamath <narayan@google.com> |
Make Date.parse() a tad more lenient.
Support zone strings of the form GMT+04:30 in addition to
GMT+0430 and GMT+5. This fixes a couple of our URLConnectionTests
in cases where server was sending back dates in this format.
As a follow-up okhttp change, we should consider overriding
URLConnection#getHeaderFieldDate so that we can avoid using Date.parse
altogether.
bug: 26326992
Change-Id: Ia1198afb18f84874a9726e46c26d575ea9ff3f45
|
| 5e50fbcd745a7687fc2930961a258048b28d2213 |
|
27-Apr-2015 |
Narayan Kamath <narayan@google.com> |
Date.toString must always use Locale.US.
bug: https://code.google.com/p/android/issues/detail?id=81924
Change-Id: Id5e0ec6514f159d548617e5d9946088078b89afa
|
| e4a3071d6f5b8ef0f9d86463524491ce0091c62a |
|
08-May-2014 |
Neil Fuller <nfuller@google.com> |
Removing data hacks from ICU root.txt
Previously, the upstream ICU data was modified
to support special short codes (e.g. PST, CET) so that
they were recognized when parsing/formatting in all
locales with SimpleDateFormat.parse()/format().
In an effort to more-closely replicate ICU this change
does *not* introduce special casing for short /
abbreviated names from Java APIs.
This may have impact for applications that use
Date.toString() (but not Date.parse()),
SimpleDateFormat.parse(), SimpleDateFormat.format(),
and anything that uses TimeZone methods that deal in
formatting and zone strings (e.g. getZoneStrings(),
getDisplayName()).
Details:
Date.parse() is unaffected because it handles abbreviated
names only, is not internationalized and contains a set
of recognized strings. Date.toString() is affected because
it relies on SimpleDateFormat for formatting.
ICU still supports abbreviated / short names for
locales where those terms are considered unambiguous for
residents of that locale. For example, "PST" is still parsed /
formatted in Locale.US when using SimpleDateFormat.
However, with this change "PST" will not be parsed/formatted
other locales such as Locale.FRANCE, Locale.UK.
If SimpleDateFormat.format() / TimeZone.getDisplayName() cannot
find a short / abbreviated name for a timezone in the
specified/defaulted locale, then a GMT offset is output as per
the docs.
Of particular note are methods that rely on Locale.getDefault()
and/or Locale.getTimeZone(). Most user-facing usecases are
expected to be unaffected. For example, US users will continue
to see / enter PST. Applications that were previously
parsing a date string containing (for example) PST but relying
on the default locale will start seeing failures.
Most of the changes are in tests that were hardcoding
expected strings or relying on the default locale.
This change is associated with a change in external/icu4c:
I04acd15c62d49c0cf30cc63f60db320bdb8e22e9
This commit also includes minor test changes related to
parsing/formatting dates where the default device locale
is assumed to be US (or other English-speaking locale).
Date-related tests that were relying on the default locale
and broke when it was set to a non-English script are now
explicitly setting it.
Note: The tests all rely on the CtsTestRunner / Vogar
resetting the default Locale / TimeZone between each test.
Bug: 11413756
Change-Id: I9ae6397cf5335ef325aedb6472d0d66a6127e1dd
|
| 32d2e33dabd6767913e275a62c456f8fe4e5131f |
|
09-Feb-2011 |
Elliott Hughes <enh@google.com> |
Simplify Date.toGMTString.
There was a reason for the madness, but Android's SimpleDateFormat implements
'y' like the Unicode standard, not the RI, so we don't need the hack to get
standard behavior manually. Add explicit tests to guard against regression.
Change-Id: Iff3cf09004c76684ce7605ede888463a86d15d92
|
| 4557728efb66c455a52b7669a8eefef7a9e54854 |
|
11-Aug-2010 |
Jesse Wilson <jessewilson@google.com> |
Moving tests to be under the libcore.* package.
This is indended to make it easier to run on VMs that restrict the packages
from which application classes can be loaded. For example, on the RI you need
to use the bootclasspath to load these tests.
Change-Id: I52193f35c5fcca18b5a3e1d280505b1e29b388af
|