Browsers, Time Zones, Chrome 67 Error (Historic Timezone Changes)

Why is new Date() returning the wrong timezone in Chrome?

Looking at this website, for Shanghai, they had a GMT+0805 from < 1800 up to 1900.

This changed in 1901 when they removed the extra 5 minutes, becoming GMT+0800.

Same reason why user Thum Choon Tat gets GMT+0646. in the comments.

This said, it looks like Chrome goes a little further than other browsers in determining the timezone.

Wrong minutes and seconds in a JavaScript date before year 1925

Prior to 1883 Time Zones were not standardized. If you check every year you'll notice that 1883 is "broken" with the additional minutes and 1884 is "fine". Chrome handles this transition very well - you'll notice the "problem" doesn't exist in Firefox.

new Date("1883-01-01T00:00:00+00:00")
Sun Dec 31 1882 16:07:02 GMT-0752 (Pacific Standard Time)
new Date("1884-01-01T00:00:00+00:00")
Mon Dec 31 1883 16:00:00 GMT-0800 (Pacific Standard Time)

In fact, you can track this down to November 18th, 1883.

new Date("1883-11-18T00:00:00+00:00")
Sat Nov 17 1883 16:07:02 GMT-0752 (Pacific Standard Time)
new Date("1883-11-19T00:00:00+00:00")
Sun Nov 18 1883 16:00:00 GMT-0800 (Pacific Standard Time)

Chrome tries very hard to match time, even going so far as to calculate the suspended DST of Ramadan in Egypt in 2010.

Read more here: https://www.huffingtonpost.com/quora/how-when-and-why-were-tim_b_5838042.html

Strange behaviour in old JavaScript dates with timezones

Your local timezone appears to have changed rules as of that date. jonrsharpe points out that timeanddate.com says this for Estonia:

1 May 1921 - Time Zone Change (TMT → EET)

When local standard time was about to reach
Sunday, 1 May 1921, 00:00:00 clocks were turned forward 0:21 hours to
Sunday, 1 May 1921, 00:21:00 local standard time instead.

If you're not in Estonia, perhaps it was similar for where you are. Looking at Wikipedia, that fits as lots of places now using Eastern European Time started doing so in 1921 and 1922.

Google app script reading different timezones from Spreadsheet

You have to set the timezone when converting the date format in order to always have the same value to consider:

var ss = SpreadsheetApp.getActiveSpreadsheet();
Utilities.formatDate(dati[0][11], ss.getSpreadsheetTimeZone(), "dd/MM/yy");

https://www.analyticstraps.com/utc-vs-gmt-vs-getspreadsheettimezone/

new Date() returning different values for time zones, with different inputs

The values you are showing are correct.

ECMAScript requires date-only values in YYYY-MM-DD format to be treated as UTC. From the spec:

... When the UTC offset representation is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.

Then the toString function converts to a string representation of local time, which takes the system time zone into account.

The IANA time zone data for India, including rich documentation comments, can be found here. The data itself is as follows (as of tzdata version 2021a):

# Zone  NAME            STDOFF    RULES    FORMAT    [UNTIL]
Zone    Asia/Kolkata    5:53:28   -        LMT       1854 Jun 28  # Kolkata
                        5:53:20   -        HMT       1870         # Howrah Mean Time?
                        5:21:10   -        MMT       1906 Jan  1  # Madras local time
                        5:30      -        IST       1941 Oct
                        5:30      1:00     +0630     1942 May 15
                        5:30      -        IST       1942 Sep
                        5:30      1:00     +0630     1945 Oct 15
                        5:30      -        IST

You can see two of the earlier offsets from your example in the second and third lines of data. If you choose an even earlier date (before 1854-06-28), you'll get the offset from the first line. You can also see that India used a +06:30 offset in two separate periods of history.

All of the history is also available in a more human-readable form at timeanddate.com here.

This is how time zones work. They are not fixed to a single numeric offset, but instead an offset applies to a time zone at a particular point in time, and that offset can change at the whim of the government which controls that time zone. For more on this, read the section titled "Time Zone != Offset" in the timezone tag wiki.

---

Related Topics