Added Area-Library label.

Removed Library-Core, Area-Library labels.
Added Area-Pkg label.

Removed Library-Intl label.
Added Pkg-Intl label.

After adding a lot of logging for this I saw the problem in a log on Friday.
http://chromegw.corp.google.com/i/client.dart/builders/dartium-lucid64-full-be/builds/2661/steps/dartium_core_unchecked_tests/logs/stdio

The log is very long, as there's lots of debug code around that now, but the relevant portion seems to be
Creating Date from
                        UTC: false
                        year: 1970
                        month: 1
                        day: 1
                        pm: false
                        hour: 0
                        minute: 58
                        second: 59
                        fractionalSecond: 0
                    Created 1970-01-01 00:58:59.000
Creating Date from
                        UTC: false
                        year: 1970
                        month: 1
                        day: 1
                        pm: false
                        hour: 0
                        minute: 0
                        second: 0
                        fractionalSecond: 0
                    Created 1969-12-31 16:00:00.000

which comes from date_format_helpers.dart lines 42-78.

So we're calling new DateTime and in one case it's producing the desired date and in the other it's applying UTC correction even though it wasn't asked for. So either the VM is doing something odd in there or the DateTime code is.

cc @kevmoo.
Removed Area-Pkg, Pkg-Intl labels.
Added Area-Library label.

Added Library-Core label.

Florian writes:
Since the output doesn't contain a "Z" at the end we know that the generated DateTime is not a UTC date-time. This means that it did take the right branch and that it did invoke the right constructor. This means that the most likely culprit is the function that gets the timezone offset: _localTimeZonAdjustmentInSeconds (in runtime/lib/date_patch.dart).
That one dispatches to OS::GetTimeZonOffsetInSeconds (runtime/vm/os_linux.cc) with the following code:
===
  tm decomposed;
  bool succeeded = LocalTime(seconds_since_epoch, &decomposed);
  // Even if the offset was 24 hours it would still easily fit into 32 bits.
  // If unsuccessful, return zero like V8 does.
  return succeeded ? static_cast<int>(decomposed.tm_gmtoff) : 0;
===

So it looks like succeeded was false and we just returned "0".
We have a few options now:

• add debug-logging to that function and figure out why it fails.
• add a loop to retry when it fails.
• throw when it doesn't succeed, instead of silently return 0.

  ---

  cc @fsc8000.
  cc @lrhn.
  cc @skabet.
  Removed the owner.

The fact that we see this, and V8 doesn't, is that because we test it better then they do?

There could be several reasons.

• better test coverage (we don't see it in our non-package tests either)
• different setup. Dart calls tzset much more often.
• different test-server. I have never seen this test fail locally so far.

Are we going to do anything about this? This causes flakiness in the DateTime tests. I suppose I can change its date creation to create the date three times and go with the majority opinion, but that doesn't seem elegant.

Changed the title to: "DateTime creation in local time zone uses UTC instead if getting the local time zone offset causes an error".

I wonder if the call to 'localtime_r' can fail with E_INTR. We could try to check for it, and call again while errno == E_INTR.

Issue #19916 has been merged into this issue.

cc @vsmenon.

https://codereview.chromium.org/399973002 has an additional workaround for this in the Intl tests.

Not stale. Still happens.

We are, however, still not fixing it.