Bisected to 7bed949c66408be72fa74397b34ddb0835b12df9 "Update V8 to version 6.7.228."
In V8 log suspecting 1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91
Reland "Implement a new spec for timezone offset calculation"
Landed in 67.0.3390.0

Able to reproduce the issue on reported chrome version 68.0.3422.0, Beta# 67.0.3396.48 and latest chrome# 68.0.3436.0 using Windows-10, Mac 10.12.6 & Ubuntu 14.04, issue is not seen on Chrome stable# 66.0.3359.181, hence providing Bisect Info
Bisect Info:
================
Good build: 67.0.3389.0
Bad build: 67.0.3390.0

You are probably looking for a change made after 548395 (known good), but no later than 548396 (first known bad).
https://chromium.googlesource.com/chromium/src/+log/f42b19bde0ce6e2d52fadc34a19b005dc236c2b8..7bed949c66408be72fa74397b34ddb0835b12df9
Suspecting from above change log: https://chromium.googlesource.com/v8/v8/+/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91
Reviewed-on: https://chromium-review.googlesource.com/572148

@Jungshik Shin: Please confirm the issue and help in re-assigning if it is not related to your change.
Adding ReleaseBlock-Stable as it is seems a receent break, feel free to remove it if not applicable.

Thanks!

M67 Stable promotion is coming VERY soon. Your bug is labelled as Beta  ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP.  Thank you.

In 1900, Russian timezone offset WAS different from 2018. THis is work-as-intended. 

The problem is not with the difference between 1900 and 2018 but the difference between Chrome <67 and 67/68. This is a breaking change but for what reason? That offset (2:30) is also incorrect strictly speaking as during 1900 Russia had Julian calendar. And adopted Gregorian calendar only in 1918.

EcmaScript spec always stipulated that Gregorian calendar be used all the way to the beginning of EcmaScript epoch. 

In 1905, Moscow time was 9017 seconds ahead of GMT (based on Moscow's longitude). 9017 seconds / 60 ~ 150. 

Note also that Europe/Moscow has changed its timezone offset and DST multiple times in recent years. (3 times since 2010). 

Until Chrome 66, these historical changes were not taken into account and multiple bugs were filed on this issue. See  bug 417640  and  bug v8:3547  and  bug v8:6031  and bugs blocked by them. 

See https://en.wikipedia.org/wiki/Moscow_Time#History  and https://www.timeanddate.com/time/zone/russia/moscow . 

In Chrome 67/68:

d8> new Date(2010,11,21).getTimezoneOffset()
-180
d8> new Date(2010,5,21).getTimezoneOffset()    
-240
d8> new Date(2011,5,21).getTimezoneOffset()
-240
d8> new Date(2011,11,21).getTimezoneOffset()
-240
d8> new Date(2015,5,21).getTimezoneOffset()
-180

In Chrome 66: 

d8> new Date(2010,11,21).getTimezoneOffset()
-180
d8> new Date(2010,5,21).getTimezoneOffset()
-240
d8> new Date(2011,5,21).getTimezoneOffset()
-180    <=====  should be -240
d8> new Date(2011,11,21).getTimezoneOffset()
-180    <====== should be -240
d8> new Date(2015,6,21).getTimezoneOffset()
-180

Thanks for the clarification.
The only pity is about the breaking change but it had to happen one day as I understand.

BTW if Chrome now supports so strict offsets like 2:30:17 
> new Date(1900,0,1).toISOString()
< "1899-12-31T21:29:43.000Z"

why does Date.getTimezoneOffset not return precise offset? As double I mean.
I guess `new Date(1900,0,1).getTimezoneOffset()` should be now 150.28(3)
So that taking (new Date(1900,0,1).getTimezoneOffset()) and multiply by 60000 we will get 9017000 and it'd the 2:30:17. No?

A good point about double vs int:

v8 has this

  // ECMA 262 - 15.9.5.26
  int TimezoneOffset(int64_t time_ms) {
    int64_t local_ms = ToLocal(time_ms);
    return static_cast<int>((time_ms - local_ms) / kMsPerMin);
  }

The spec has (https://tc39.github.io/ecma262/#sec-date.prototype.gettimezoneoffset )

The following steps are performed:

Let t be ? thisTimeValue(this value).
If t is NaN, return NaN.
Return (t - LocalTime(t)) / msPerMinute.


I'll file a separate bug on that. And perhaps, I'll propose a spec edit to add a note about an non-integral offset.

Filed a new v8 issue:  bug v8:7863 . I'll also raise an issue in github ecma 262.