Hmm... the root cause of this issue may be this code snippet in base/platform/platform-linux.cc

const char* OS::LocalTimezone(double time, TimezoneCache* cache) {
#if V8_OS_NACL
  // Missing support for tm_zone field.
  return "";
#else
  if (std::isnan(time)) return "";
  time_t tv = static_cast<time_t>(std::floor(time/msPerSecond));
  struct tm* t = localtime(&tv);
  if (NULL == t) return "";
  return t->tm_zone;
#endif
}

double OS::LocalTimeOffset(TimezoneCache* cache) {
#if V8_OS_NACL
  // Missing support for tm_zone field.
  return 0;
#else
  time_t tv = time(NULL);
  struct tm* t = localtime(&tv);
  // tm_gmtoff includes any daylight savings offset, so subtract it.
  return static_cast<double>(t->tm_gmtoff * msPerSecond -
                             (t->tm_isdst > 0 ? 3600 * msPerSecond : 0));
#endif
}


The above code snippet explains how Korean time (Asia/Seoul) appears to work properly while Europe/Moscow does not. 

v8 calculates the tz offset from the tz offset of the current tz rule in effect and apply it to any past/future time with isDst to add an hour. 

This would not work if tz offset has changed over time as is the case of Europe/Moscow. 

+sgjesse who appears to have implemented the above. 

There are quite a lot of timezones whose offset have changed over time (e.g. America/Indiana/*, America/Phoenix, ....) and for which the current implementation will not work properly. 

 

There are a couple of possibilities here:

1. Port what ICU does to v8. ICU got it right on most (if not all) platforms including various Unix-like OS
2. Now that v8 already relies on ICU for ECMAScript I18N API, use ICU directly if I18N API is enabled. If it's not enabled, keep the current (not working) code as it is? 

Ulan, could you take a look to see if this is still an issue?

Chrome 40.0.2214.115 (64-bit) still think that 2014-06-01T12:20:03Z is 15:00 of Moscow time. Firefox works correctly (16:00).

 Issue chromium:294037  has been merged into this issue.

There still seems to be a bug for this mismatch between what ICU outputs and what our Date formatter outputs for these Russian dates. In the Moscow time zone, I saw this in the console in Chrome 48:

> new Date("6/1/2014")
Sun Jun 01 2014 00:00:00 GMT+0300 (MSK)
> new Date("6/1/2014").toLocaleString("en")
"6/1/2014, 1:00:00 AM"

The second approach of comment 4 might be rather simple to implement. We can override Date.prototype.toString in i18n.js with toLocaleString with options to match the output format of the current toString as closely as possible. 

I'll try that. 

Well, there's a caveat. The default timezone in Intl.DateTimeFormat is not updated upon a timezone change.  So, that bug has to be solved first. 

One of related bugs is
 bug chromium:466014 

I believe  bug chromium:417640  is a duplicate of this bug. 
The current timezone offset is applied to the past when a given timezone has a different UTC offset. 

> Well, there's a caveat. The default timezone in Intl.DateTimeFormat is not 
> updated upon a timezone change.  So, that bug has to be solved first.

It is updated (Intl.DateTimeFormat().resolvedOptions().timeZone), but toLocaleString() still holds onto the old value. 

Ok. toLocaleString() without any option uses a cached object while toLocaleString(....) with any option uses a new one and works correctly. 

Because the second approach in comment 4 requires calling toLocaleString() with non-default options,  cached DateTimeFormatter holding on to the old value does not matter.

Made a CL at https://codereview.chromium.org/1973183002. The CL does cache Intl.DateTimeFormat. So, it has  bug chromium:466014  (even for toString,toDateString,toTimeString). 

I'll update it to fix both this bug and  bug chromium:466014  by updating the tz in cached Intl.DateTimeFormat. 

The CL was updated to reset the default timezone in cached DateTimeFormat. It should work fine on Mac/Windows (any case) and Linux/CrOS (in existing render processes). 

On Linux/CrOS, new tabs(render process) do not get a new TimeZone. That's because a Zygote process is created with the timezone in effect at the start of browser process. This is not a v8 issue but a Chrome issue. Filed  bug chromium:612010 

Because I have a CL (wip), I'll take this over. 

As a fix for  bug 5022 , timezone invalidation is being already done (my next step). So, I'll just update my CL to  utilize that. 

LC_ALL=ru_RU.UTF-8 out/rel/d8 (current trunk) 
V8 version 5.7.0 (candidate)
d8> sep1_2014_noon = new Date("09/01/2014 12:00Z")
Mon Sep 01 2014 15:00:00 GMT+0300 (MSK)    <=== should be 16:00 
d8> sep1_2014_noon.toLocaleString()
"01.09.2014, 16:00:00"      <==== This is correct

With my updated CL ( https://codereview.chromium.org/1973183002 )

$ LC_ALL=ru_RU.UTF-8 out/deb/d8
V8 version 5.7.0 (candidate)
d8>  sep1_2014_noon = new Date("09/01/2014 12:00Z")
Mon, Sep 01, 2014, 16:00:00 GMT+4
d8> sep1_2014_noon.toLocaleString()
"01.09.2014, 16:00:00"

The CL does not touch Date() constructor so that this one will not fix  bug 5714  completely. However, an issue related to the historical timezone should be fixed with this change. 

There are a couple of caveats with landing the CL:

1. Without fixing  bug chromium:612010 , a new tab (as opposed to an existing tab) will have a wrong timezone upon a timezone change

2. Date.toString() output format will be different (especially timezone)

Old: 
d8> new Date()
Thu Jan 05 2017 13:20:33 GMT-0800 (PST)

New: 
d8> new Date()
Thu, Jan 05, 2017, 13:20:20 PST

> 2. Date.toString() output format will be different (especially timezone)

This looks like a very breaking change, several JS code bases depend on the quite standard `toString` output.

A quick look at Firefox and Safari seems to show them printing out timezones in a similar way to what V8 does now. What's the motivation of rhat part of the change?

>  What's the motivation of rhat part of the change?

There's no motivation. I would have imitate the current format exactly if possible. See https://github.com/tc39/ecma402/issues/119
I'm trying to emulate the current toString output as faithfully as possible with options available for Intl.DateTimeFormat. 

It'd be still possible but with a lot more changes. 

> several JS code bases depend on the quite standard `toString` output.

How would they depend on that? Do they parse the output? I thought that Ecma262 gave a lot of leeway for 'Date.toString' output. 

>> several JS code bases depend on the quite standard `toString` output.

> How would they depend on that? Do they parse the output? 
> I thought that Ecma262 gave a lot of leeway for 'Date.toString' output. 

BTW, it appears that v8's Date.toString() uses a localized timezone name while it does not on Linux. 

So, I'm not sure how much the current behavior can be relied upon by other JS libraries.

> How would they depend on that? Do they parse the output? I thought that Ecma262 gave a lot of leeway for 'Date.toString' output.
> BTW, it appears that v8's Date.toString() uses a localized timezone name while it does not on Linux. 
> So, I'm not sure how much the current behavior can be relied upon by other JS libraries.

I'm sorry for disruption, actually I cannot provide clear evidence of usage, but I personally feel that the `toString` representation implementations, although standardized as "an implementation-dependent String value" ( https://tc39.github.io/ecma262/#sec-todatestring ), are quite standard and provide *some* information (especially the localized timezone information) that cannot be obtained from other Date APIs without including big external databases like CLDR. Maybe Intl API provides this information as well, but it's not quite cross-browser as of now, especially on not-so-old-IE and mobile iOS ( http://caniuse.com/#search=intl ).

> especially the localized timezone information

So, what and how do you get the above information ("localized timezone information"; I'm not sure what you meant by that, btw. do you mean the timezone offset? ) from the output of Date.protype.toString() in a cross-browser manner? 

Intl.DateTimeFormat().resolvedOptions().timeZone works in Chrome/v8 to get the default timezone, but Firefox didn't add support for non-UTC timezone to Intl.DateTimeFormat until 52.x (Aurota). 

One more thing: 
v8 on Windows gives this output (en-US locale)
Tue Jan 10 2017 11:15:53 GMT-0800 (Pacific Standard Time)

v8 on Linux gives this output (in all locales, afaict)

Tue Jan 10 2017 11:22:54 GMT-0800 (PST)

babak.john@: do they depend on 'GMT{+-}hhmm' part to get the timezone offset? 

But, Date already has a better method for that. getTimezoneOffset()

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTimezoneOffset

Having written comment 29 reminded me that just overriding Date.prototype.to*String() with Intl one does not fix other timezone-related methods for Date. For instance, getTimezoneOffset() would be still incorrect for the past or future date if the timezone rules are different from the current rules. 

Two approaches can be considered:

1. Override all timezone related methods (for which timezone rule changes matters) with Intl ones (in i18n.js / runtime-i18n.cc / i18n.cc). 

2. Rewrite Date.* completely with ICU when i18n is enabled. 

$ sudo timedatectl  set-timezone Europe/Moscow
$ out/rel/d8
V8 version 5.7.0 (candidate)

# In 2014, Europe/Moscow was UTC+0400 in September.

d8>  sep1_2014_noon = new Date("09/01/2014 12:00Z")
Mon Sep 01 2014 15:00:00 GMT+0300 (MSK)  <=== should be 16:00 GMT+0400
d8> sep1_2014_noon.getTimezoneOffset()
-180    <==  should be -240

# In 2016, Europe/Moscow is UTC+0300
d8> sep1_2016_noon = new Date("09/01/2016 12:00Z")
Thu Sep 01 2016 15:00:00 GMT+0300 (MSK)
d8> sep1_2016_noon.getTimezoneOffset()
-180

> > especially the localized timezone information
> 
> So, what and how do you get the above information ("localized timezone information"; I'm not sure what you meant by that, btw. do you mean the timezone offset? ) from the output of Date.protype.toString() in a cross-browser manner? 

I didn't mean cross-browser. I meant "some information" that can be displayed to the users for them to read and understand as they want.

> One more thing: 
> v8 on Windows gives this output (en-US locale)
> Tue Jan 10 2017 11:15:53 GMT-0800 (Pacific Standard Time)

> v8 on Linux gives this output (in all locales, afaict)
> Tue Jan 10 2017 11:22:54 GMT-0800 (PST)

By localized timezone info I meant this part: "(Pacific Standard Time)" and "(PST)".

> Having written comment 29 reminded me that just overriding Date.prototype.to*String() with Intl one does not fix other timezone-related methods for Date. For instance, getTimezoneOffset() would be still incorrect for the past or future date if the timezone rules are different from the current rules. 

And this is even more important thing for proper past time timezones, because by not having that, the code cannot properly guess the timezone name from the set of timezone offsets (unfortunately, I experienced that the one from Intl timeZone is not always pertinent to the actual user timezone) and thus cannot use that inaccurate timezone name to get the user display string from CLDR instead of the string provided by Date toString.

There are all sorts of methods that can break in Date with a wrong timezone offset. 

d8> Sep1_2014 = new Date("2014-09-01T20:15Z")
Mon Sep 01 2014 23:15:00 GMT+0300 (MSK)  <=== Sep 02 2014 00:15:00 GMT+0400
d8> Sep1_2014.getHours()
23    <=== should be 0
d8> Sep1_2014.getDay() 
1    <==== should be 2

At the end/beginning of a {month,year}, even get{Month,Year}() can be off by one. 

I think the best is to 

1) Use ICU for the timezone calculation for Date when i18n is enabled. Then, get{Day,Hours,Month,Year} etc will be automatically correct
2) Rewrite to*String() methods in terms of ICU
   a) Override them with Intl.DateTimeFormat as is done in my CL above
   b) Add a separate implementation with ICU. 

Hmm... Ecma262 spec seems to assume that LocalTZA and DaylightTZA do not change over time:

Quote from http://www.ecma-international.org/ecma-262/6.0/#sec-localtime (Ecma262 6.0 )

20.3.1.7 Local Time Zone Adjustment

An implementation of ECMAScript is expected to determine the local time zone adjustment. The local time zone adjustment is a value LocalTZA measured in milliseconds which when added to UTC represents the local standard time. Daylight saving time is not reflected by LocalTZA.

NOTE It is recommended that implementations use the time zone information of the IANA Time Zone Database http://www.iana.org/time-zones/.

20.3.1.8 Daylight Saving Time Adjustment

An implementation dependent algorithm using best available information on time zones to determine the local daylight saving time adjustment DaylightSavingTA(t), measured in milliseconds. An implementation of ECMAScript is expected to make its best effort to determine the local daylight saving time adjustment.

NOTE It is recommended that implementations use the time zone information of the IANA Time Zone Database http://www.iana.org/time-zones/.

20.3.1.9 LocalTime ( t )

The abstract operation LocalTime with argument t converts t from UTC to local time by performing the following steps:
ReturnIfAbrupt(t).
Return t + LocalTZA + DaylightSavingTA(t).
20.3.1.10 UTC ( t )

The abstract operation UTC with argument t converts t from local time to UTC is defined by performing the following steps:
ReturnIfAbrupt(t).
Return t – LocalTZA – DaylightSavingTA(t – LocalTZA).
NOTEUTC(LocalTime(t)) is not necessarily always equal to t.

------------------

https://tc39.github.io/ecma262/#sec-local-time-zone-adjustment (2017 draft is about the same). 

AbstractOperations |LocalTime()| and |UTC()| do not seem well-defined with timezone rule changes over the time for a given location (say, Europe/Moscow). 

jshin, This sounds like a spec bug. Would you be interested in writing a spec patch to fix it?

As I alluded in comment 34, Ecma 262 spec itself is buggy/problematic. 
It assumes that LocalTZA (local timezone adjustment) is CONSTANT over the history !!!

See http://www.ecma-international.org/ecma-262/6.0/#sec-utc-t and https://github.com/tc39/ecma262/issues/725

Dan, I'll try if it's simple, but the model for Date() seems rather ugly and I'm still trying to understand it completely. 

Despite the spec, Firefox does the right thing from a user's pov: 

Below is taken from Firefox 50.1.0 on Mac OS X. Note that the OS timezone was set to Europe/Moscow. It's UTC+0400 in July 2014 but UTC+0300 in July 2016. 

Jul31_2014 = new Date("2014-07-31T20:15Z")
Date 2014-07-31T20:15:00.000Z
Jul31_2014.toString()
"Fri Aug 01 2014 00:15:00 GMT+0400 (MSK)"
Jul31_2014.toLocaleString("en")
"8/1/2014, 12:15:00 AM"
Jul31_2014.getHours()
0                                
Jul31_2014.getMonth()
7
Jul31_2014.getDate()
1

Jul31_2016 = new Date("2016-07-31T20:15Z")
Date 2016-07-31T20:15:00.000Z
Jul31_2016.toString()
"Sun Jul 31 2016 23:15:00 GMT+0300 (MSK)"
Jul31_2016.toLocaleString("en")
"7/31/2016, 11:15:00 PM"

---------

OTOH, v8 gives the following:

--------
Jul31_2014 = new Date("2014-07-31T20:15Z")
Thu Jul 31 2014 23:15:00 GMT+0300 (MSK)   <==== should be GMT+0400
Jul31_2014.getMonth()
6                 <======  should be 7 
Jul31_2014.getDate()
31                           <===== should be 1
Jul31_2014.getHours()
23                           <===== should be 0
Jul31_2014.toString()
"Thu Jul 31 2014 23:15:00 GMT+0300 (MSK)"
Jul31_2014.toLocaleString()
"2014. 8. 1. 오전 12:15:00"
Jul31_2014.toLocaleString("en")
"8/1/2014, 12:15:00 AM"

Jul31_2016 = new Date("2016-07-31T20:15Z")
Sun Jul 31 2016 23:15:00 GMT+0300 (MSK)
Jul31_2016.toString()
"Sun Jul 31 2016 23:15:00 GMT+0300 (MSK)"
Jul31_2016.toLocaleString("en")
"7/31/2016, 11:15:00 PM"
-----------

Firefox and Safari behave identically (as expected by users): 

From Firefox:

aug1_2014_0315_msklocal = new Date(2014,7,1,3,15)
Date 2014-07-31T23:15:00.000Z      <= Europe/Moscow was UTC+04
aug1_2016_0315_msklocal = new Date(2016,7,1,3,15)
Date 2016-08-01T00:15:00.000Z      <== Europe/Moscow was UTC+03

From Safari:

> aug1_2014_0315_msklocal = new Date(2014,7,1,3,15)
< Fri Aug 01 2014 03:15:00 GMT+0400 (MSK)
> aug1_2014_0315_msklocal.toLocaleString("en", {'timeZone': 'UTC'})
< "7/31/2014, 11:15:00 PM"
> aug1_2016_0315_msklocal = new Date(2016,7,1,3,15)
< Mon Aug 01 2016 03:15:00 GMT+0300 (MSK)
> aug1_2016_0315_msklocal.toLocaleString("en", {'timeZone': 'UTC'})
< "8/1/2016, 12:15:00 AM"

From Chrome/v8:

aug1_2014_0315_msklocal = new Date(2014,7,1,3,15)
Fri Aug 01 2014 03:15:00 GMT+0300 (MSK)
aug1_2014_0315_msklocal.toLocaleString("en", {'timeZone': 'UTC'})
"8/1/2014, 12:15:00 AM"         <===  should be '7/31/2014 11:15:00 PM'



Local Time Zone Adjustment in Ecma 262 (unlike DST Adjustment) is independent of 't' (as is specified), but actual implementations (Firefox/SpiderMonkey and Safari/JSC) do seem to make it time-dependent as expected by users. 

20.3.1.7Local Time Zone Adjustment#

An implementation of ECMAScript is expected to determine the local time zone adjustment. The local time zone adjustment is a value LocalTZA measured in milliseconds which when added to UTC represents the local standard time. Daylight saving time is not reflected by LocalTZA.

NOTE
It is recommended that implementations use the time zone information of the IANA Time Zone Database http://www.iana.org/time-zones/.

20.3.1.8Daylight Saving Time Adjustment#

An implementation dependent algorithm using best available information on time zones to determine the local daylight saving time adjustment DaylightSavingTA(t), measured in milliseconds. An implementation of ECMAScript is expected to make its best effort to determine the local daylight saving time adjustment.

NOTE
It is recommended that implementations use the time zone information of the IANA Time Zone Database http://www.iana.org/time-zones/.


-----------

While the spec is being revised, I guess we can align v8 with JSC and Spidermonkey because that's what users expect. 

I made a PR wrt tc39/ecma262 at https://github.com/tc39/ecma262/pull/778 . 

As I noted in  https://github.com/tc39/ecma262/issues/725,  both Firefox and Safari are broken for Pacific/Apia around the end of 2011-12-29 (local time) when it switched from UTC-10 to UTC+14 (2011-12-30 was entirely skipped in that timezone.). 

Anyway, I believe a consensus has been building at https://github.com/tc39/ecma262/pull/778 (although repeated time/skipped time handling behavior is the opposite of my initial PR). 

re comment 21:
> 1. Without fixing  bug chromium:612010 , a new tab (as opposed to an existing tab) will have a wrong timezone upon a timezone change


The above bug is only an issue on Linux/CrOS. (no doubt we have to fix it).  

bug chromium:612341 may or may not complicate fixing  bug chromium:612010 . (I came up with a couple of ideas last night before seeing bug chromium:612341). 

Dan submitted a CL to use ICU for Date objects (toString, getTimeZoneOffset, etc) instead of the OS API behind a flag. 

If we turn that flag ON by default, a lot of issues (including this one) will be fixed. 

> a lot of issues (including this one) will be fixed. 

Including this one : Turning that flag ON is a prerequisite for fixing this bug.  On top of that, we need to implement  https://github.com/tc39/ecma262/pull/778 . 

I just made a WiP (not completed) CL for that: 
https://chromium-review.googlesource.com/572148

> Including this one : Turning that flag ON is a prerequisite for fixing this bug.

Actually not. Just implementing  https://github.com/tc39/ecma262/pull/778 (except for is_utc part) fixes a lot of problems without turning on --icu-timezone-data. 

For instance, Europe/Moscow in 2014 and 2009 work correctly whether the current time is 2017 or Sep 2014 because with pull/778 implemented, LocalTZA is not fixed any more but depends on the time value of a Date object. 

Still turning on icu-timezone-data would be desirable because in some cases OS tz data is not up to date or OS API that can be used by v8 inside a sandbox does not work correctly for some tricky timezone transitions.  

Moreover, a full implementation of pull/778 (LocalTZA's is_utc dependency) is much simpler with ICU than with OS APIs. 

Anyway, I'll add tests to the CL in comment 46 and ask for review. 

Yes, currently, the --icu-timezone-data flag does *not* implement that PR. It sticks with the previous data model, just using different data.

https://chromium-review.googlesource.com/572148 is a CL to implement the PR. 

With that, most of bugs here (even without icu-timezone-data) would be fixed. And, I suspect that IE/Edge has effectively been doing that. 

What's not fixed is Pacific/Apia that skipped an entire day (2011-12-30) when transitioning from UTC-10 to UTC+14. 

With icu-timezone-data and https://chromium-review.googlesource.com/572148 ,  Pacific/Apia is also fixed. 

> With icu-timezone-data and https://chromium-review.googlesource.com/572148 

The ICU CL is at 
https://chromium-review.googlesource.com/572652

> With that, most of bugs here (even without icu-timezone-data) would be fixed. 

I was too quick to say the above. (I only tested with timezones west of the Greenwich when I wrote that).  Perhaps, it's possible to do that in most timezones without icu-timezone-data (with some platform-dependent tweaking), but it'd be much simpler with icu-timezone-data than without it. 

http://bugs.icu-project.org/trac/ticket/13268 is an ICU bug necessary for the implemenation of https://github.com/tc39/ecma262/pull/778 . I could go with my ICU patch ( https://chromium-review.googlesource.com/572652 ), but I'd rather fix it in the upstream (in an upstream-sanctioned way). 

I updated my CL at https://chromium-review.googlesource.com/c/v8/v8/+/572148 . 

I also have a better ICU CL (more likely to be accepted by the upstream) at
https://chromium-review.googlesource.com/c/chromium/deps/icu/+/851265 . 

I'm also looking into the possibility of landing the above v8 CL without  bug 6031  resolved (that is, making this bug fixed for "most" of time in most of timezones with icu-timezone-data option enabled).  

> I'm also looking into the possibility of landing the above v8 CL without  bug 6031  resolved (that is, making this bug fixed for "most" of time in most of timezones with icu-timezone-data option enabled).  

 with icu-timezone-data option enabled) ==>  without icu-timezone-data option enabled. 

I updated https://chromium-review.googlesource.com/c/v8/v8/+/572148 . (it does not require an ICU change). 


Without icu-timezone-data, I settled on implementing the new spec ( https://github.com/tc39/ecma262/pull/778 ) correctly for timezones whose
standard zone offset is the same as the current standard zone offset (e.g.
most North American zones).  

With icu-timezone-data, all the historical changes (e.g. Europe/Moscow, Europe/Minsk, Pacific/Apia) are correctly supported. 

So, to fix bugs related to historic timezone offset shifts that depend on this bug, we have to enable icu-timezone-data after figuring out the root cause of perf regression (4% ~ 40% ? ). 

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/dbdede0101270b4ea332e52544215fe3c4a9bd71

commit dbdede0101270b4ea332e52544215fe3c4a9bd71
Author: Jungshik Shin <jshin@chromium.org>
Date: Tue Apr 03 17:56:25 2018

Implement a new spec for timezone offset calculation

https://github.com/tc39/ecma262/pull/778 was recently merged
to Ecma 262.

It changes the way to convert between "local time" and UTC in such
a way that it'd work for all timezones whether or not there has
been any change in the timezone offset of the standard time. For
instance, Europe/Moscow and some parts of US state of Indiana have
changed the standard (non-DST) timezone offset a few times. The
previous spec assumes that the the standard timezone offset is
constant, but the new spec take into account the offset change
history.

In addition, it specifies a new way to calculate the timezone
offset during a timezone transition (either in and
out of DST or timezone offset shift).

During a negative transition (e.g.  fall backward / getting
out of DST), repeated times are to be interpreted as if the
offset before the transition is in effect.

During a positive transition (e.g. spring forward / getting
into DST), skipped times are to be treated similarly. That
is, they are to be interpreted as if the offset before the
transition is in effect.

With icu-timezone-data, v8 is compliant to the new spec for the
past and the future as well as now whether or not the standard
timezone offset of a given timezone has changed over time
(e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
Australia/Lord_Howe (30 minute DST change) also works per spec.

Without icu-timezone-data, it works only for timezones of which
the standard timezone offset is the same as the current offset
(e.g. most North American timezones other than parts of Indiana)
and of which the DST shift is an hour. For instance, it doesn't work
for Europe/Moscow in 2010 when the standard timezone offset was
+4h because the current (2018) standard timezone offset is +3h. Neither
does it for Lord Howe in Australia with the DST shift of 0.5 hr.

This CL used to require one of the two ICU CLs below, but not
any more.

  https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
  https://chromium-review.googlesource.com/851265  (a proposed CL to the
  upstream ICU).

Bug:  v8:3547 , chromium:417640 , v8:5714 
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
Reviewed-on: https://chromium-review.googlesource.com/572148
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52332}
[modify] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/src/base/platform/platform-aix.cc
[modify] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/src/base/platform/platform-cygwin.cc
[modify] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/src/base/platform/platform-posix-time.cc
[modify] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/src/base/platform/platform-posix-time.h
[modify] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/src/base/platform/platform-solaris.cc
[modify] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/src/base/platform/platform-win32.cc
[modify] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/src/base/timezone-cache.h
[modify] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/src/date.cc
[modify] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/src/date.h
[modify] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/src/intl.cc
[modify] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/src/intl.h
[modify] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/test/cctest/test-date.cc
[modify] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/test/mjsunit/mjsunit.status
[add] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/test/mjsunit/tzoffset-seoul-noi18n.js
[add] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/test/mjsunit/tzoffset-seoul.js
[add] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/test/mjsunit/tzoffset-transition-apia.js
[add] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/test/mjsunit/tzoffset-transition-lord-howe.js
[add] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/test/mjsunit/tzoffset-transition-moscow.js
[add] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/test/mjsunit/tzoffset-transition-new-york-noi18n.js
[add] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/test/mjsunit/tzoffset-transition-new-york.js
[modify] https://crrev.com/dbdede0101270b4ea332e52544215fe3c4a9bd71/test/mozilla/mozilla.status

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/965edc0e2e3fb817d7274016121e5eca3dcc16e6

commit 965edc0e2e3fb817d7274016121e5eca3dcc16e6
Author: Clemens Hammacher <clemensh@chromium.org>
Date: Tue Apr 03 22:07:32 2018

Revert "Implement a new spec for timezone offset calculation"

This reverts commit dbdede0101270b4ea332e52544215fe3c4a9bd71.

Reason for revert: Fails webkit_tests, blocks roll: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064

Original change's description:
> Implement a new spec for timezone offset calculation
> 
> https://github.com/tc39/ecma262/pull/778 was recently merged
> to Ecma 262.
> 
> It changes the way to convert between "local time" and UTC in such
> a way that it'd work for all timezones whether or not there has
> been any change in the timezone offset of the standard time. For
> instance, Europe/Moscow and some parts of US state of Indiana have
> changed the standard (non-DST) timezone offset a few times. The
> previous spec assumes that the the standard timezone offset is
> constant, but the new spec take into account the offset change
> history.
> 
> In addition, it specifies a new way to calculate the timezone
> offset during a timezone transition (either in and
> out of DST or timezone offset shift).
> 
> During a negative transition (e.g.  fall backward / getting
> out of DST), repeated times are to be interpreted as if the
> offset before the transition is in effect.
> 
> During a positive transition (e.g. spring forward / getting
> into DST), skipped times are to be treated similarly. That
> is, they are to be interpreted as if the offset before the
> transition is in effect.
> 
> With icu-timezone-data, v8 is compliant to the new spec for the
> past and the future as well as now whether or not the standard
> timezone offset of a given timezone has changed over time
> (e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
> Australia/Lord_Howe (30 minute DST change) also works per spec.
> 
> Without icu-timezone-data, it works only for timezones of which
> the standard timezone offset is the same as the current offset
> (e.g. most North American timezones other than parts of Indiana)
> and of which the DST shift is an hour. For instance, it doesn't work
> for Europe/Moscow in 2010 when the standard timezone offset was
> +4h because the current (2018) standard timezone offset is +3h. Neither
> does it for Lord Howe in Australia with the DST shift of 0.5 hr.
> 
> This CL used to require one of the two ICU CLs below, but not
> any more.
> 
>   https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
>   https://chromium-review.googlesource.com/851265  (a proposed CL to the
>   upstream ICU).
> 
> Bug:  v8:3547 , chromium:417640 , v8:5714 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
> Reviewed-on: https://chromium-review.googlesource.com/572148
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52332}

TBR=adamk@chromium.org,littledan@chromium.org,mlippautz@chromium.org,jshin@chromium.org

Change-Id: I6b3bf4427c761b106280d565a3912cd8e25cf87e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  v8:3547 ,  chromium:417640 ,  v8:5714 
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/994192
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52338}
[modify] https://crrev.com/965edc0e2e3fb817d7274016121e5eca3dcc16e6/src/base/platform/platform-aix.cc
[modify] https://crrev.com/965edc0e2e3fb817d7274016121e5eca3dcc16e6/src/base/platform/platform-cygwin.cc
[modify] https://crrev.com/965edc0e2e3fb817d7274016121e5eca3dcc16e6/src/base/platform/platform-posix-time.cc
[modify] https://crrev.com/965edc0e2e3fb817d7274016121e5eca3dcc16e6/src/base/platform/platform-posix-time.h
[modify] https://crrev.com/965edc0e2e3fb817d7274016121e5eca3dcc16e6/src/base/platform/platform-solaris.cc
[modify] https://crrev.com/965edc0e2e3fb817d7274016121e5eca3dcc16e6/src/base/platform/platform-win32.cc
[modify] https://crrev.com/965edc0e2e3fb817d7274016121e5eca3dcc16e6/src/base/timezone-cache.h
[modify] https://crrev.com/965edc0e2e3fb817d7274016121e5eca3dcc16e6/src/date.cc
[modify] https://crrev.com/965edc0e2e3fb817d7274016121e5eca3dcc16e6/src/date.h
[modify] https://crrev.com/965edc0e2e3fb817d7274016121e5eca3dcc16e6/src/intl.cc
[modify] https://crrev.com/965edc0e2e3fb817d7274016121e5eca3dcc16e6/src/intl.h
[modify] https://crrev.com/965edc0e2e3fb817d7274016121e5eca3dcc16e6/test/cctest/test-date.cc
[modify] https://crrev.com/965edc0e2e3fb817d7274016121e5eca3dcc16e6/test/mjsunit/mjsunit.status
[delete] https://crrev.com/2ade52e93bc85a83f76c12ceea52d3b723029ff5/test/mjsunit/tzoffset-seoul-noi18n.js
[delete] https://crrev.com/2ade52e93bc85a83f76c12ceea52d3b723029ff5/test/mjsunit/tzoffset-seoul.js
[delete] https://crrev.com/2ade52e93bc85a83f76c12ceea52d3b723029ff5/test/mjsunit/tzoffset-transition-apia.js
[delete] https://crrev.com/2ade52e93bc85a83f76c12ceea52d3b723029ff5/test/mjsunit/tzoffset-transition-lord-howe.js
[delete] https://crrev.com/2ade52e93bc85a83f76c12ceea52d3b723029ff5/test/mjsunit/tzoffset-transition-moscow.js
[delete] https://crrev.com/2ade52e93bc85a83f76c12ceea52d3b723029ff5/test/mjsunit/tzoffset-transition-new-york-noi18n.js
[delete] https://crrev.com/2ade52e93bc85a83f76c12ceea52d3b723029ff5/test/mjsunit/tzoffset-transition-new-york.js
[modify] https://crrev.com/965edc0e2e3fb817d7274016121e5eca3dcc16e6/test/mozilla/mozilla.status

geolocation-api/timestamp.html failed: 

FAIL t <= then + 1 should be true. Was false.

I added a debug output and got this: 

  t = 1522801879359
  then + 1 = 1522801457391 

I'm a bit clueless as to why this change break geolocation-api/timestamp.html. 

Adding Reilly to see if he has any idea or pointer. (Sorry for picking you among a few people who recently touched the test. It's not clear who's the best). 

Ok. At least, now I understand what the test tries to test. It's still how this test failed.   The difference between |t| and |then| is also interesting. If timezone is somehow mis-detected or something, it'd be close to a multiple of 60,000 (if not 3,600,000 or 1,800,000)

1522801879359-1522801457390
421969
(1522801879359-1522801457390)/1000/60
7.03281666666666666666
(1522801879359-1522801457390)/1000
421.96900000000000000000

Actually, the diff is close to a multiple of 60,000 (42,196). So, it may have something to do with a conflation between UTC and local time (I ran the test in UTC-7). 

But, the unit of timestamp and Date.prototype.getTime() is milliseconds (not 1/1000 minutes)...

It's possible that mock geolocation has an issue while the real one is fine. 

I think I figured out the cause. As expected, geoLocation mock has a bug. 

https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/geolocation-api/resources/geolocation-mock.js?rcl=59deb360661b808a61f88790b4b9d8be7a22a1e2&l=95

    const windowsEpoch = new Date(1601,1,1,0,0,0,0);
    const unixEpoch = new Date(1970,1,1,0,0,0,0);

The above two lines should have used Date.UTC() or just hard-coded the constant value.  

It makes a false assumption that the timezone offset has not changed in a given timezone.  And, the whole point of my CL is to take into account historical changes in the timezone offset. In year 1601, there was no standard timezone and local side realtime for Los_Angeles was not UTC-7. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b0aed69d5e92440e6aa7500a9aad47a792069aae

commit b0aed69d5e92440e6aa7500a9aad47a792069aae
Author: Jungshik Shin <jshin@chromium.org>
Date: Wed Apr 04 16:48:05 2018

Fix geolocation mock to calculate the correct epoch delta

When calculating the delta between Windows Epoch and Unix Epoch in
geolocation mock, Date constructor (that interpretes
parameters in terms of *local* time) was used for the Windows
epoch (1601-01-01) and Unix epoch (1970-01-01) assuming that the
timezone offset didn't change between 1601 and 1970. That assumption
does not hold any more when ICU is used to take into account
the historical timezone offset changes. As a result,
geolocation-api/timestamp.html test failed when the fix for v8:3547
was landed. (https://chromium-review.googlesource.com/c/v8/v8/+/572148 ).

This CL uses Date.UTC() to avoid the issue and is a pre-requisite
to relanding the above v8 CL.

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_layout_ng
Bug:  v8:3547 ,  chromium:417640 ,  v8:5714 
Test: layout test: geolocation-api/*
Change-Id: Iaf718c2818fa9a5f5c64136a38579a1fcafe7805
Reviewed-on: https://chromium-review.googlesource.com/994343
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548095}
[modify] https://crrev.com/b0aed69d5e92440e6aa7500a9aad47a792069aae/third_party/WebKit/LayoutTests/geolocation-api/resources/geolocation-mock.js
[modify] https://crrev.com/b0aed69d5e92440e6aa7500a9aad47a792069aae/third_party/WebKit/LayoutTests/geolocation-api/timestamp.html

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91

commit 1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91
Author: Jungshik Shin <jshin@chromium.org>
Date: Wed Apr 04 22:42:30 2018

Reland "Implement a new spec for timezone offset calculation"

This is a reland of dbdede0101270b4ea332e52544215fe3c4a9bd71
after a webkit layout test (geolocation-api/timestamp.html) was
fixed by
https://chromium-review.googlesource.com/c/chromium/src/+/994343 .

Original change's description:
> Implement a new spec for timezone offset calculation
>
> https://github.com/tc39/ecma262/pull/778 was recently merged
> to Ecma 262.
>
> It changes the way to convert between "local time" and UTC in such
> a way that it'd work for all timezones whether or not there has
> been any change in the timezone offset of the standard time. For
> instance, Europe/Moscow and some parts of US state of Indiana have
> changed the standard (non-DST) timezone offset a few times. The
> previous spec assumes that the the standard timezone offset is
> constant, but the new spec take into account the offset change
> history.
>
> In addition, it specifies a new way to calculate the timezone
> offset during a timezone transition (either in and
> out of DST or timezone offset shift).
>
> During a negative transition (e.g.  fall backward / getting
> out of DST), repeated times are to be interpreted as if the
> offset before the transition is in effect.
>
> During a positive transition (e.g. spring forward / getting
> into DST), skipped times are to be treated similarly. That
> is, they are to be interpreted as if the offset before the
> transition is in effect.
>
> With icu-timezone-data, v8 is compliant to the new spec for the
> past and the future as well as now whether or not the standard
> timezone offset of a given timezone has changed over time
> (e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
> Australia/Lord_Howe (30 minute DST change) also works per spec.
>
> Without icu-timezone-data, it works only for timezones of which
> the standard timezone offset is the same as the current offset
> (e.g. most North American timezones other than parts of Indiana)
> and of which the DST shift is an hour. For instance, it doesn't work
> for Europe/Moscow in 2010 when the standard timezone offset was
> +4h because the current (2018) standard timezone offset is +3h. Neither
> does it for Lord Howe in Australia with the DST shift of 0.5 hr.
>
> This CL used to require one of the two ICU CLs below, but not
> any more.
>
>   https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
>   https://chromium-review.googlesource.com/851265  (a proposed CL to the
>   upstream ICU).
>
> Bug:  v8:3547 , chromium:417640 , v8:5714 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
> Reviewed-on: https://chromium-review.googlesource.com/572148
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52332}

Bug:  v8:3547 ,  chromium:417640 ,  v8:5714 
Change-Id: I47536c111143f75e3cfeecf5d9761c43a98a10f5
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/995971
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52372}
[modify] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/src/base/platform/platform-aix.cc
[modify] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/src/base/platform/platform-cygwin.cc
[modify] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/src/base/platform/platform-posix-time.cc
[modify] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/src/base/platform/platform-posix-time.h
[modify] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/src/base/platform/platform-solaris.cc
[modify] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/src/base/platform/platform-win32.cc
[modify] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/src/base/timezone-cache.h
[modify] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/src/date.cc
[modify] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/src/date.h
[modify] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/src/intl.cc
[modify] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/src/intl.h
[modify] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/test/cctest/test-date.cc
[modify] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/test/mjsunit/mjsunit.status
[add] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/test/mjsunit/tzoffset-seoul-noi18n.js
[add] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/test/mjsunit/tzoffset-seoul.js
[add] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/test/mjsunit/tzoffset-transition-apia.js
[add] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/test/mjsunit/tzoffset-transition-lord-howe.js
[add] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/test/mjsunit/tzoffset-transition-moscow.js
[add] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/test/mjsunit/tzoffset-transition-new-york-noi18n.js
[add] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/test/mjsunit/tzoffset-transition-new-york.js
[modify] https://crrev.com/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91/test/mozilla/mozilla.status

Fixed