Fix core lib DateTime in the VM.

Fix core lib DateTime in the VM (fixes #19923).

Symptom of the problem:
Set your Linux workstation (or Mac or MIPS board) to the Europe/London timezone
and the corelib/date_time test will fail, claiming that 1/1/1970 was a Wednesday
(it was actually a Thursday, trust me, I was already born).

Problem:
The implementation of DateTime in the VM relies on Unix time_t, the number of
seconds since the Epoch (1/1/1970 UTC). When asked for the weekday of a given
time, our implementation limits itself to a 32-bit positive range of time_t.
If the time falls outside of this range, the implementation picks an equivalent
time in the valid range with the same weekday, also in leap year or not, etc...
The issue is that DateTime is using the underlying OS in an inconsistent manner.
Let's take the example above: 1/1/1970 in the Europe/London timezone.
First, the number of seconds since the Epoch in UTC is calculated, here 0.
Then, the timezone offset at the given time is calculated using the underlying
OS. In this case, an historical deviation is taken into account. Indeed, London
stayed on British Summer Time between 27 October 1968 and 31 October 1971. See
https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of_deviation for
details.
Our resulting time is therefore negative (one hour difference with UTC).
When asked about the weekday of this time, the implementation notices that the
time is not in the positive range and picks an "equivalent" time in the future.
It then asks the underlying OS about the timezone offset for this time, which
is 0 (usually no daylight saving time in January in London). Unfortunately,
this time is not really equivalent, because it ignores the original historical
deviation. The result is wrongly equivalent to 12/31/1969 23:00 in London, i.e.
a Wednesday, and not a Thursday as expected.

Solution:
We should use the underlying OS in a consistent way, by simply allowing the
value of time_t passed to the underlying OS to be negative, which is legal.

R=floitsch@google.com, rmacnak@google.com

Committed: https://github.com/dart-lang/sdk/commit/48dc7903980e728e6e88b3588714be49c62f5a91

[regis, 2016-03-30 00:37:02]

regis@google.com changed reviewers:
+ floitsch@google.com, rmacnak@google.com

[floitsch, 2016-03-30 16:01:32]

Thanks for doing this!
I have often tried to figure out if time_t could be negative and found
contradicting information on the web.
However, I agree, that we have enough tests to make sure that our VM works on
all the supported platforms.

Please add the following bug number to this CL and close it, once you commit.
http://dartbug.com/19923

LGTM!

[floitsch, 2016-03-30 16:03:05]

On 2016/03/30 16:01:32, floitsch wrote:
> Thanks for doing this!
> I have often tried to figure out if time_t could be negative and found
> contradicting information on the web.
> However, I agree, that we have enough tests to make sure that our VM works on
> all the supported platforms.
> 
> Please add the following bug number to this CL and close it, once you commit.
> http://dartbug.com/19923
> 
> LGTM!

One minor request: please update the Changelog file.

[regis, 2016-03-30 16:38:01]

Description was changed from

==========
Fix core lib DateTime in the VM.

Symptom of the problem:
Set your Linux workstation (or Mac or MIPS board) to the Europe/London timezone
and the corelib/date_time test will fail, claiming that 1/1/1970 was a Wednesday
(it was actually a Thursday, trust me, I was already born).

Problem:
The implementation of DateTime in the VM relies on Unix time_t, the number of
seconds since the Epoch (1/1/1970 UTC). When asked for the weekday of a given
time, our implementation limits itself to a 32-bit positive range of time_t.
If the time falls outside of this range, the implementation picks an equivalent
time in the valid range with the same weekday, also in leap year or not, etc...
The issue is that DateTime is using the underlying OS in an inconsistent manner.
Let's take the example above: 1/1/1970 in the Europe/London timezone.
First, the number of seconds since the Epoch in UTC is calculated, here 0.
Then, the timezone offset at the given time is calculated using the underlying
OS. In this case, an historical deviation is taken into account. Indeed, London
stayed on British Summer Time between 27 October 1968 and 31 October 1971. See
https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of_deviation for
details.
Our resulting time is therefore negative (one hour difference with UTC).
When asked about the weekday of this time, the implementation notices that the
time is not in the positive range and picks an "equivalent" time in the future.
It then asks the underlying OS about the timezone offset for this time, which
is 0 (usually no daylight saving time in January in London). Unfortunately,
this time is not really equivalent, because it ignores the original historical
deviation. The result is wrongly equivalent to 12/31/1969 23:00 in London, i.e.
a Wednesday, and not a Thursday as expected.

Solution:
We should use the underlying OS in a consistent way, by simply allowing the
value of time_t passed to the underlying OS to be negative, which is legal.
==========

to

==========
Fix core lib DateTime in the VM (fixes #19923).

Symptom of the problem:
Set your Linux workstation (or Mac or MIPS board) to the Europe/London timezone
and the corelib/date_time test will fail, claiming that 1/1/1970 was a Wednesday
(it was actually a Thursday, trust me, I was already born).

Problem:
The implementation of DateTime in the VM relies on Unix time_t, the number of
seconds since the Epoch (1/1/1970 UTC). When asked for the weekday of a given
time, our implementation limits itself to a 32-bit positive range of time_t.
If the time falls outside of this range, the implementation picks an equivalent
time in the valid range with the same weekday, also in leap year or not, etc...
The issue is that DateTime is using the underlying OS in an inconsistent manner.
Let's take the example above: 1/1/1970 in the Europe/London timezone.
First, the number of seconds since the Epoch in UTC is calculated, here 0.
Then, the timezone offset at the given time is calculated using the underlying
OS. In this case, an historical deviation is taken into account. Indeed, London
stayed on British Summer Time between 27 October 1968 and 31 October 1971. See
https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of_deviation for
details.
Our resulting time is therefore negative (one hour difference with UTC).
When asked about the weekday of this time, the implementation notices that the
time is not in the positive range and picks an "equivalent" time in the future.
It then asks the underlying OS about the timezone offset for this time, which
is 0 (usually no daylight saving time in January in London). Unfortunately,
this time is not really equivalent, because it ignores the original historical
deviation. The result is wrongly equivalent to 12/31/1969 23:00 in London, i.e.
a Wednesday, and not a Thursday as expected.

Solution:
We should use the underlying OS in a consistent way, by simply allowing the
value of time_t passed to the underlying OS to be negative, which is legal.
==========

[rmacnak, 2016-03-30 16:41:53]

lgtm w/ 64-bit comparison

https://codereview.chromium.org/1845483002/diff/1/runtime/lib/date.cc
File runtime/lib/date.cc (right):

https://codereview.chromium.org/1845483002/diff/1/runtime/lib/date.cc#newcode15
runtime/lib/date.cc:15: static int32_t kMaxAllowedSeconds = kMaxInt32;
static int64_t kMaxAllowedSeconds = kMaxInt32;

https://codereview.chromium.org/1845483002/diff/1/runtime/lib/date.cc#newcode21
runtime/lib/date.cc:21: if (abs(seconds) > kMaxAllowedSeconds) {
llabs(seconds)

https://codereview.chromium.org/1845483002/diff/1/runtime/lib/date.cc#newcode33
runtime/lib/date.cc:33: if (abs(seconds) > kMaxAllowedSeconds) {
llabs(seconds)

[regis, 2016-03-30 17:09:36]

Thank you both!

I was not aware of issue 19923. I commented on it and added a reference from
this cl.

As requested, I updated the changelog under 1.16, although no API change
occurred. So I am not sure it is really necessary. The note can still be removed
before we ship.

https://codereview.chromium.org/1845483002/diff/1/runtime/lib/date.cc
File runtime/lib/date.cc (right):

https://codereview.chromium.org/1845483002/diff/1/runtime/lib/date.cc#newcode15
runtime/lib/date.cc:15: static int32_t kMaxAllowedSeconds = kMaxInt32;
On 2016/03/30 16:41:53, rmacnak wrote:
> static int64_t kMaxAllowedSeconds = kMaxInt32;

Done.

https://codereview.chromium.org/1845483002/diff/1/runtime/lib/date.cc#newcode21
runtime/lib/date.cc:21: if (abs(seconds) > kMaxAllowedSeconds) {
On 2016/03/30 16:41:53, rmacnak wrote:
> llabs(seconds)

Done.

https://codereview.chromium.org/1845483002/diff/1/runtime/lib/date.cc#newcode33
runtime/lib/date.cc:33: if (abs(seconds) > kMaxAllowedSeconds) {
On 2016/03/30 16:41:53, rmacnak wrote:
> llabs(seconds)

Done.

[regis, 2016-03-30 17:10:02]

Description was changed from

==========
Fix core lib DateTime in the VM (fixes #19923).

Symptom of the problem:
Set your Linux workstation (or Mac or MIPS board) to the Europe/London timezone
and the corelib/date_time test will fail, claiming that 1/1/1970 was a Wednesday
(it was actually a Thursday, trust me, I was already born).

Problem:
The implementation of DateTime in the VM relies on Unix time_t, the number of
seconds since the Epoch (1/1/1970 UTC). When asked for the weekday of a given
time, our implementation limits itself to a 32-bit positive range of time_t.
If the time falls outside of this range, the implementation picks an equivalent
time in the valid range with the same weekday, also in leap year or not, etc...
The issue is that DateTime is using the underlying OS in an inconsistent manner.
Let's take the example above: 1/1/1970 in the Europe/London timezone.
First, the number of seconds since the Epoch in UTC is calculated, here 0.
Then, the timezone offset at the given time is calculated using the underlying
OS. In this case, an historical deviation is taken into account. Indeed, London
stayed on British Summer Time between 27 October 1968 and 31 October 1971. See
https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of_deviation for
details.
Our resulting time is therefore negative (one hour difference with UTC).
When asked about the weekday of this time, the implementation notices that the
time is not in the positive range and picks an "equivalent" time in the future.
It then asks the underlying OS about the timezone offset for this time, which
is 0 (usually no daylight saving time in January in London). Unfortunately,
this time is not really equivalent, because it ignores the original historical
deviation. The result is wrongly equivalent to 12/31/1969 23:00 in London, i.e.
a Wednesday, and not a Thursday as expected.

Solution:
We should use the underlying OS in a consistent way, by simply allowing the
value of time_t passed to the underlying OS to be negative, which is legal.
==========

to

==========
Fix core lib DateTime in the VM (fixes #19923).

Symptom of the problem:
Set your Linux workstation (or Mac or MIPS board) to the Europe/London timezone
and the corelib/date_time test will fail, claiming that 1/1/1970 was a Wednesday
(it was actually a Thursday, trust me, I was already born).

Problem:
The implementation of DateTime in the VM relies on Unix time_t, the number of
seconds since the Epoch (1/1/1970 UTC). When asked for the weekday of a given
time, our implementation limits itself to a 32-bit positive range of time_t.
If the time falls outside of this range, the implementation picks an equivalent
time in the valid range with the same weekday, also in leap year or not, etc...
The issue is that DateTime is using the underlying OS in an inconsistent manner.
Let's take the example above: 1/1/1970 in the Europe/London timezone.
First, the number of seconds since the Epoch in UTC is calculated, here 0.
Then, the timezone offset at the given time is calculated using the underlying
OS. In this case, an historical deviation is taken into account. Indeed, London
stayed on British Summer Time between 27 October 1968 and 31 October 1971. See
https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of_deviation for
details.
Our resulting time is therefore negative (one hour difference with UTC).
When asked about the weekday of this time, the implementation notices that the
time is not in the positive range and picks an "equivalent" time in the future.
It then asks the underlying OS about the timezone offset for this time, which
is 0 (usually no daylight saving time in January in London). Unfortunately,
this time is not really equivalent, because it ignores the original historical
deviation. The result is wrongly equivalent to 12/31/1969 23:00 in London, i.e.
a Wednesday, and not a Thursday as expected.

Solution:
We should use the underlying OS in a consistent way, by simply allowing the
value of time_t passed to the underlying OS to be negative, which is legal.

R=floitsch@google.com, rmacnak@google.com

Committed:
https://github.com/dart-lang/sdk/commit/48dc7903980e728e6e88b3588714be49c62f5a91
==========

[regis, 2016-03-30 17:10:03]

Committed patchset #3 (id:40001) manually as
48dc7903980e728e6e88b3588714be49c62f5a91 (presubmit successful).