Can we get any update on this need an update regarding this. This makes a serious issue while accessing dates from server.

From the original thread -
Note that in 1937, there was no daylight saving time in Tripoli and it was GMT + 1 throughout the entire year so the correct date would be 25, not 26.
Reference -
https://www.timeanddate.com/time/change/libya/tripoli?year=1937

I tried this code and it kept returning the same results when I tried in different Chrome versions -
a = new Date("1937-02-25T22:00:00.000Z")
console.log(new Intl.DateTimeFormat("en-us", {timeZone: 'Africa/Tripoli', era: "long", hour: "numeric", day: "numeric", month: "numeric", year: "numeric", minute: "numeric", second: "numeric", timeZoneName: "long"}).format(a));
console.log(new Intl.DateTimeFormat("en-us", {timeZone: 'Asia/Jerusalem', era: "long", hour: "numeric", day: "numeric", month: "numeric", year: "numeric", minute: "numeric", second: "numeric", timeZoneName: "long"}).format(a));

Edge 17 (and the Insider preview) does show 26, which seems to be wrong. Firefox 61 and Safari 11.1 show the same as Chrome.

Hint - new Intl.DateTimeFormat().resolvedOptions() will tell you what time zone the browser thinks you use. You can compare the results in 65 (if you still have it somewhere) versus 67 or the version you use.

But if I have a entry of date value with date 26 in my server when I read it now if it becomes 25 is this acceptable? Does this make any sense? Why come this occurs only now in chromre latest version alone but not with previous versions and also not with other browsers??

Able to reproduce the issue on Win-10 and Ubuntu 17.10 (high dpi) machine using chrome reported version #67.0.3396.99 and latest canary #70.0.3500.0. Issue is not seen in OS-mac.
This is a non-regression issue as it is observed from M60 old builds. 
Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

Can we get any update on this please

I am confused. Comment #6 says that this was happening in M60 already, how come you can only observe it on the latest Chrome?

Re #4: Depends in what format you transport the date. Timestamp maybe?

#9 -
My guess is that the reproduction in #6 was conducted without changing the locale to Tripoli.

Unable to test the issue as per the url i.e https://codepen.io/anon/pen/bjbodJ in comment #0 as the page is not loading on navigating to that url.

kprem886@ - Could you please provide any other sample file/url to test the issue from our end. 
Thanks...!!

please find the issue reproduced samples from the below link. i hope this sample will be run without any issues.

https://plnkr.co/edit/gOXqv7MYYJ5EQdyNOwNy?p=preview

Thanks..

#13 - if anything, you should file a new issue for this different issue (year parsing issue, rather than date and time zone issue). Also, mention in the new issue if you see the expected results in other browsers (and which).

I'm replicating the issue based on #0. #11 reported as, the url i.e https://codepen.io/anon/pen/bjbodJ was not working.

So, i have prepared the sample in new online editor with same case and same issue mentioned in #0.

#14 I'm also facing the same issue in my machine too with latest chrome browser.

Thanks.

#15 - the year issue seems much unrelated to this issue, so if you want that issue to be investigated, you should file a new issue.
Facing the same issue does not justify adding unrelated issues to this issue, you can star this issue instead.

The original URL seems to fail due to the HTML comment (I guess CodePen changed something) at the beginning of the JavaScript code. I forked it not to have that comment and it now runs.
https://codepen.io/phistuck/pen/wxLRQo

hi @phistuck,

Can you please udpate whether this is confirmed as an issue or not?. 

Thanks

#17 - nope, I am not a Chrome team member, my opinion does not count as much. ;)

hi @phitstuck

Thanks