Seems like this is actually not a bug, but a proper representation after 1883:

https://www.wired.com/2010/11/1118railroad-time-zones/

Could you verify?

Able to reproduce the issue on reported chrome version 67.0.3396.62  & latest chrome 69.0.3450.0 using  Ubuntu 14.04,Windows10 & Mac 10.13.3 and Hence providing the bisect information below.

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

You are probably looking for a change made after 541769 (known good), but no later than 541770 (first known bad)

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/ecd916766fcea37603d7b56f858c5bdf19c42071..a4a4697bf72d1226591f1493a8408610c124b0f7

suspect: https://chromium.googlesource.com/v8/v8/+/ae314567068815d494ef206db54a887cdd614db7

Reviewed-on: https://chromium-review.googlesource.com/857333

jshin@: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!

This is working as intended and working per spec. The spec says that we have to follow the IANA timezone database. 

In 1880, there's no standard timezone and America/Los_Angeles timezone offset was based on its longitude. The same is true of other timezones. 

Also note that there are many timezone around the world the zone offset (and whether or not to have DST or when to start DST) have changed multiple times even since 2000 (e.g. Europe/Moscow).  The change to make them work correctly  also brought in what's reported here. 

> timezone around the world the zone offset (....) have changed

should read

 timezone around the world the zone offset  of which have changed ....

 Issue v8:7843  has been merged into this issue.

You have merged my issue into this, and closed this one as Wont Fix.
You should really try my issue as it is returning the wrong minutes for an old date. A date time for example of 1800-01-01 11:00 is reporting minutes of 58 and hour of 10. That is a bug in the latest build of Chrome v67.

Our current workaround to our users is to recommend using any other browser other than Chrome. We don't want to do that of course.

re: comment 9

Europe/London in 1800 was NOT in UTC. Note that London's longitude is not exactly 0 but slightly west of Greenwich (the location of the primary meridian ). That slight difference is reflected in 1 minute 15 sec difference.  Go to https://www.timeanddate.com/time/zone/uk/london and select 1800-1850. Note that London adopted the standard time (Greenwich) in year 1847. 

 Issue 844504  has been merged into this issue.

 Issue 847978  has been merged into this issue.

 Issue 850876  has been merged into this issue.

 Issue 852298  has been merged into this issue.

 Issue 852321  has been merged into this issue.

 Issue 853124  has been merged into this issue.

 Issue 853463  has been merged into this issue.

re: comment 10
I hear you, but you surely cannot think a date of 1800-01-01 and time of 11:00 to give hours and minutes of 10 and 58 to be correct, right? When would you EVER expect that to be the desired behavior?
This is either a bug or a design flaw with the changes made in v67. You pick.

I don't agree with the won't fix decision. 

I can understand the talks about timezone offset based on longitude in certain locations in certain years before there is even a thing called UTC.

But how about an ISO 8601 date time string with timezone info?

When parsing such a string, I would not expect Chromium to change the info for me. As it has nothing to do with locations, no assumptions need to be made because...

1>
`If **no** UTC relation information is given with a time representation, the time is assumed to be in local time.`
https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators

In other words, With a UTC timezone info, no assumptions should be made.

2>
`Coordinated Universal Time (abbreviated to UTC) is the primary time standard by which the world regulates clocks and time. It is within about 1 second of mean solar time at 0° longitude, and does not observe daylight saving time.`
https://en.wikipedia.org/wiki/Coordinated_Universal_Time

UTC also represents the time at 0° longitude. So UTC matches the old longitude calculation.

var x = new Date('1900-01-01T08:30:00+08:00')
x.getTimezoneOffset()

The returned result should always be -480 as stated in the string instead of -485.

How come Javascript's start date of Jan 1st, 1970 could return different timezone offset for Singapore Standard Time.

new Date(1970, 0, 1).getTimezoneOffset() returns -450 instead of -480 after v67. To me this is clearly a regression issue.

Won't fix is not what we expect from Chrome.

> new Date(1970, 0, 1).getTimezoneOffset() returns -450 instead of -480 after v67. To me this is clearly a regression issue.


In 1970, Asia/Singapore was UTC+0730. See https://en.wikipedia.org/wiki/Singapore_Standard_Time

 Issue 860254  has been merged into this issue.

> new Date(1970, 0, 1)

The Unix epoch is 1970-01-01T00:00:00 in UTC. It's not in any random timezone whose offset changed over time. 

re: comment 20

> var x = new Date('1900-01-01T08:30:00+08:00')
> x.getTimezoneOffset()

> The returned result should always be -480 as stated in the string instead of -485.

You misunderstood what Date ctor does given an input like yours. It does NOT do anything about the timezone offset of the current default timezone. If you want to change it, use your OS timezone settings. 

Try this

var x = new Date('1900-01-01T08:30:00+08:00');
var y = new Date('1900-01-01T00:30+00:00');
x.getTimeZoneOffset()
y.getTimeZoneOffset()
x.toString()
y.toString()
x.getTime()
y.getTime()

>> new Date(1970, 0, 1)

>The Unix epoch is 1970-01-01T00:00:00 in UTC. It's not in any random timezone whose offset changed over time. 

Except you're not getting "1970-01-01T00:00:00 in UTC" when you create the Date object with new Date(1970, 0, 1). You get "1970-01-01T00:00:00 in browser's local timezone". You actually cannot truly switch away from the inherent local timezone of the browser. You can do new Date('1970-01-01T00:00:00Z') and get the correct timestamp, but it will still print out that timestamp in your local timezone in the console. And methods like .getHours() would produce values in your local timezone.

Date of birth counts down in Chrome v67 in our application.

A birth date before 1940 counts down when you edit a booking in our application. The dates after 1940 remain correct. 
Ex: 14/03/1930 (see prt scrs below)

Is this a bug in Chrome? Will this be resolved and if so, when? 
If no, why not? Why did you make this change and other browsers did not.
There are apparently more people with this problem.

Regards.

The issue has been marked as "WontFix" so, no it will probably not be fixed.
The way I worked around it is by using MomentJS and just passing date strings, you can just format your date and supply the format to moment.
For instance: moment("1930-03-14","YYYY-MM-DD").format();
The same concept can be applied with plain JS too:
new Date("1930-03-14").toString();
Of course you lose any concept of the timezone, but in my experience that's usually not necessary anyway and you wouldn't want to display an adjusted date of birth according on the viewers timezone but rather their official date of birth on their legal documents (which usually come without time anyway).
Hope this workaround helps

Good point that we don't expect the date of birth on our passport to change depending on the time zone we are in ... altough this could lead to some very interesting discussions ;-).
However, this doesn't explain why we only see this issue for dates before 1940. As long as we don't know the reason for this behavior I would appreciate that some investigation is done .
 

> A birth date before 1940 counts down when you edit a booking in our application. 

The reason was explained multiple times. Depending on where your timezone is, the timezone offset history is different. It can be 1940, it can be 1905, 1967, 1970. It can be 187x or whatever.  Different timezones have different timezone offset history.  

BTW, another work-around for timezone offset changing over time is to store date (if you care only about date) as 'Date at noon' (12:00) instead of midnight.  Some timezone offset changes are larger than 12 hours, but the vast majority of offset change is at most a few hours (usually less than an hour). So, if you only care about 'Date' (not time), this work-around is a good defence against timezone offset change over the time. 

> Except you're not getting "1970-01-01T00:00:00 in UTC" when you create the Date object with new Date(1970, 0, 1).

Yes. Who said otherwise? 

> You get "1970-01-01T00:00:00 in browser's local timezone". 

Yes. did I say otherwise? 

> You actually cannot truly switch away from the inherent local timezone of 
> the browser. You can do new Date('1970-01-01T00:00:00Z') and get the correct timestamp, but it will still print out that timestamp in your local timezone in the console. And methods like .getHours() would produce values in your local timezone.

Yes. again, who said otherwise? 

Date has  getUTCHours() etc for a reason !

It also has Date.UTC for a reason.

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


 

>Yes. Who said otherwise? 
The comment, that I was replying to, was written in a way that seemed to imply that, ha ha, – I thought I was answering to yet another person distraught by the change.

As for storing date as time-at-noon, that's usually intrinsically not possible. Many databases have an explicit Date type used for a column like Date of Birth (as in "without time" rather than a separate DateTime type that also exists). And the database itself would treat it like time-at-midnight when converting to DateTime explicitly OR implicitly. Then there's no way to distinguish those dates from true timestamps that have the time portion when you're down to JavaScript. In theory, even if you could distinguish the two on the backend and try to handle the first ones as "treat as UTC" and the second ones as "treat as Local", you still have to pass that distinction as some separate field to the browser code. And hello ugly code there.

The worst part is – on the backend there might not be the same information about timezone offset history at all. In my case ( issue 852321 ), while it's "Europe/Kiev" on the client browser side and Chrome has all those historic changes from IANA TZ DB, the backends have to work with Microsoft Timezone Database and overe there it's just the "FLE Timezone" which means "(GMT+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius". That's a simple blanket mupltiple countries covering timezone (with a DST change too), but no particular Kyiv history. It doesn't really have a correspondence to an IANA TZData timezone (that could be potentially "set" in the browser), but its +02:00 / +03:00 offsets worked well in sync with Chrome until version 67 (without the ugly code). And still works for other browsers as far as I've seen.

You don't have to reply to this, it's not an argument against the WIA / WontFix status, I'm just giving context. Due to this Chrome issue, we had to have some philosophy discussions, such as what Date of Birth truly means. For example, your actual physical date of birth moment (with time) as a timestamp might not be on that particular same day of your particular home timezone. What does it truly mean to be born on that day then...

 Issue 867806  has been merged into this issue.

re: comment 33

Thank you for the explanation. 

Your trouble comes from two different concepts of time one of which is more suitable for your need than the other. able for your need. What you need to is  'floating time'.  See 

http://w3c.github.io/i18n-drafts/articles/definitions-time/index.en.html

For floating time, you don't need to care about timezone at all. 

Quoting from the article: 

> Floating times are not attached and should never be attached to a particular time zone.

This is a good article to define terms, but what's on the practical side? What is there to help implement this? I don't know of any extra methods that would treat a Date object as floating time rather than global time.

 Issue 871785  has been merged into this issue.