Description
From the mailing-list:
The following test
test('Strange date inequality', () => Expect.equals(new
Date.fromString('2012-02-08'), new Date(2012, 2, 8, 0, 0, 0, 0)));
fails in Chrome with
11 FAIL Expectation: Strange date inequality. Expect.equals(expected:
<2012-02-08 00:00:00.000>, actual: <2012-02-07 23:00:00.000>) fails.
Apparently the second date which is created with the constructor that
does not take a timezone gets my local timezone applied (Central
European Time) and is then converted into a UTC date while the first
one stays as it is.
And if I try to get rid of those timezone problems and just define the
second date as an UTC date like this
test('Strange date inequality', () => Expect.equals(new
Date.fromString('2012-02-08'), new Date.withTimeZone(2012, 2, 8, 0, 0,
0, 0, new TimeZone.utc())));
I get
11 FAIL Expectation: Strange date inequality. Expect.equals(expected:
<2012-02-08 00:00:00.000>, actual: <2012-02-08 00:00:00.000Z>) fails.
I think most applications don't care about timezone. They just need
dates to stay as they are defined. Can we get a SimpleDate or
something like that without this timezone overhead?
Even stranger than that. Date.fromString doesn't seem to be
implemented in Dart VM. Executing the test in Dartium or directly in
Dart VM yields:
Caught UNIMPLEMENTED