Date inconsistencies

[floitschG]

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

[DartBot]

This comment was originally written by @rbeeger

---

I've played a bit more with this. Changing the test to

    test('Strange date inequality', () => Expect.equals(new Date.fromString('2012-02-08 00:00:00'), new Date(2012, 2, 8, 0, 0, 0, 0)));

fixes it in the Dart VM, Dartium and Chrome

But executing it in Firefox or Safari gives me:
14 ERROR Expectation: Strange date inequality. Caught Error: Invalid Date

The following two tests
    test('Strange date inequality 2', () => Expect.equals('2012-02-08 00:00:00.000', new Date.fromString('2012-02-08 00:00:00.000').toString()));
    test('Strange date inequality 3', () => Expect.equals(8, new Date.fromString('2012-02-08 00:00:00.000').day));

work in Dart VM, but in Chrome I get the following errors:
15 FAIL Expectation: Strange date inequality 2. Expect.equals(expected: <2012-02-08 00:00:00.000>, actual: <2012-02-07 23:00:00.000>) fails.
16 FAIL Expectation: Strange date inequality 3. Expect.equals(expected: <8>, actual: <7>) fails.

[floitschG]

thanks. this will help a lot.

[floitschG]

This bug has been fixed with r4630.
We still need the spec to tell us what exactly new Date.fromString should do, though: issue #1878.

---

Added Fixed label.

[DartBot]

This comment was originally written by @rbeeger

---

That doesn't seem to fix it. Testing it with Dart Editor 4760 (the latest integration build), my three tests
    test('Strange date inequality', () => Expect.equals(new Date.fromString('2012-02-08 00:00:00'), new Date(2012, 2, 8, 0, 0, 0, 0)));
    test('Strange date inequality 2', () => Expect.equals('2012-02-08 00:00:00.000', new Date.fromString('2012-02-08 00:00:00.000').toString()));
    test('Strange date inequality 3', () => Expect.equals(8, new Date.fromString('2012-02-08 00:00:00.000').day));

now consistently fail in Chrome, Firefox and Safari with
14 FAIL Expectation: Strange date inequality. Expect.equals(expected: <2012-01-31 00:00:00.000>, actual: <2012-02-08 00:00:00.000>) fails.
Expect.equals(expected: <2012-01-31 00:00:00.000>, actual: <2012-02-08 00:00:00.000>) fails.
15 FAIL Expectation: Strange date inequality 2. Expect.equals(expected: <2012-02-08 00:00:00.000>, actual: <2012-01-31 00:00:00.000>) fails.
Expect.equals(expected: <2012-02-08 00:00:00.000>, actual: <2012-01-31 00:00:00.000>) fails.
16 FAIL Expectation: Strange date inequality 3. Expect.equals(expected: <8>, actual: <31>) fails.
Expect.equals(expected: <8>, actual: <31>) fails.

The earlier failures could be explained with Timezone changes, but now I don't understand why 2012-02-08 is interpreted as 2012-01-31.

Shortening the dates to only the dates without any time data, changes this a bit, but it still stays strange
    test('Strange date inequality (short)', () => Expect.equals(new Date.fromString('2012-02-08'), new Date(2012, 2, 8, 0, 0, 0, 0)));
    test('Strange date inequality 2 (short)', () => Expect.equals('2012-02-08', new Date.fromString('2012-02-08').toString()));
    test('Strange date inequality 3 (short)', () => Expect.equals(8, new Date.fromString('2012-02-08').day));

17 FAIL Expectation: Strange date inequality (short). Expect.equals(expected: <2012-02-08 01:00:00.000>, actual: <2012-02-08 00:00:00.000>) fails.
Expect.equals(expected: <2012-02-08 01:00:00.000>, actual: <2012-02-08 00:00:00.000>) fails.
18 FAIL Expectation: Strange date inequality 2 (short). Expect.equals(expected: <2012-02-08>, actual: <2012-02-08 01:00:00.000>) fails.
Expect.equals(expected: <2012-02-08>, actual: <2012-02-08 01:00:00.000>) fails.
19 PASS Expectation: Strange date inequality 3 (short).

Somehow the date and time part get mixed up as the following tests demonstrate:
    test('Strange date inequality 4 (short)', () => Expect.equals('2012-02-08 09:00:00.000', new Date.fromString('2012-02-08 09:00:00.000').toString()));
    test('Strange date inequality 5 (short)', () => Expect.equals('2012-02-08 12:00:00.000', new Date.fromString('2012-02-08 12:00:00.000').toString()));

with the following result:
20 FAIL Expectation: Strange date inequality 4 (short). Expect.equals(expected: <2012-02-08 09:00:00.000>, actual: <2012-01-31 00:00:00.000>) fails.
Expect.equals(expected: <2012-02-08 09:00:00.000>, actual: <2012-01-31 00:00:00.000>) fails.
21 FAIL Expectation: Strange date inequality 5 (short). Expect.equals(expected: <2012-02-08 12:00:00.000>, actual: <2012-01-31 12:00:00.000>) fails.
Expect.equals(expected: <2012-02-08 12:00:00.000>, actual: <2012-01-31 12:00:00.000>) fails.

[floitschG]

I will look into this tomorrow. On my latest build the tests succeed, but I just (some hours ago) submitted other changes to the Date.fromString constructor.
In any case I will try to figure out what went wrong and add the missing tests.

---

Added Accepted label.

[floitschG]

This was already fixed in an earlier commit, but I added a test case in r4937.
What happened: Date.fromString would split the input "2012-02-08 09:00:00.000" into their respective sub-parts: "2012", "02", "08", ... and then call Math.parseInt on them. However the Math.parseInt function (in the JS version) was mapping directly to JS' parseInt function which saw the leading "0" and parsed the numbers as octal numbers. In particular "08" was then parsed as "0" which is not part of February anymore (the range needed to be 1-29) thus giving the 31th of January.

---

Added Fixed label.