Able to reproduce the issue on reported version 67.0.3396.30 & on latest chrome canary 68.0.3424.0 using Windows 10,Mac OS 10.13, Ubuntu 14.04. Hence providing bisect information below

After running per-revision bisect for two times we ended up getting bad builds. Hence providing manual bisect information from ""omahaproxy.appspot.com""

Bisect Info:
================
Good build: 67.0.3365.0
Bad build: 67.0.3366.0


CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/bd6f8d977d1e7c6b5e71e95fc085f2dd126062b4..36cbc24e0e99afca6e45d8f791d0653eb566f0fb

Note: Unable to find the suspect from above CL hence marking it as untriage and can any of the team help to find the suspect.

Thanks!

> What went wrong?
> oDate === Fri Jan 01 0010 00:53:28 GMT+0053 (Central European Standard Time)

> Time and timezone are wrong

No, nothing is wrong. This is working-as-expected. In year 10, there's no timezone (tz name inside paren is misleading). There's no DST, either. 
So, the local-side-real time is used. 

Dan, do you think we need to add an explicit spec provision (perhaps, just a note)  about Date before the standard timezone kicked in?  Implicitly, the current v8 behavior is already sanctioned by referencing IANA timezone database. 

Ok I accept that the timezone isn't wrong but I'm still wondering about the time.
I'm creating a new date object setting the time explicit to 0 and after changing the UTCFullYear the minutes are changed to 53.

To be a bit more precise with my question.
I guess the minutes are affected by the timezone value +0053 (even if I don't understand why the seconds are changed to 28 each time as well) but I don't understand where this comes from.
I created a date object right now at 13:51 local time (GMT+0200) with given parameters (2000, 0, 1, 0, 0, 0) and I only changed the UTCFullYear by setting it to year 10.
The result is Fri Dec 31 0010 23:53:28 GMT+0053 (Central European Standard Time). (I don't know why I get 23 instead of 00 for hours today as well. Yesterday I got allways 00 for hours).
Therefore I'm not sure what you mean with "local-side-real time is used".
Even if the timezone is adjusted to no timezone I'd rather expect that it returns the UTC time.

In year 10, there was no standard time zone. So, it uses "Local Mean Time" (pls, ignore local sidereal time) based on the longitude of the location. 

oDate = new Date(Date.UTC(2000, 0, 1, 0, 0, 0))
oDate.setUTCFullYear(10)

oDate has time value corresponding to 0010-01-01T00:00:00 UTC.  You can confirm that by printing out with the following :

oDate.toLocaleString("en", {timeZone: "UTC"}); 

"1/1/10, 12:00:00 AM"

Compare that with 

oDate.toLocaleString("en", {timeZone: "Europe/Berlin"});

"1/1/10, 12:53:28 AM"

In year 10, 'local mean time' of Berlin was 53 minutes and 28 seconds ahead of UTC because Berlin is 13.37 East. 

Go to https://www.timeanddate.com/time/zone/germany/berlin and select 1800-1849 in the section "Time Changes in Berlin Over the Years".