Wrong timezone for China/Schanghai

[philipp-serfling]

According to wiki
The abbr. CST stands both for Central Standard Time (North America) and China Standard Time

If you set your timezone on your PC to Shanghai, moment determines timezone:
America/Chicago

System
Ubuntu, FF or Chrome
"moment": "2.18.1", "moment-timezone": "0.5.13"

[maggiepint]

Would this be the same as #503?

[mattjohnsonpint]

Can you please tell me what you get in your browser debug console for:

console.log(Intl.DateTimeFormat().resolvedOptions().timeZone);

Also, can you tell me if you have modified your TZ environment variable on Ubuntu, outside of the time zone selection UI? What does bash show for:

printenv TZ

[philipp-serfling]

Yes, of course.
For my real position in germany i get CET

If i set my timezone to Shanghai i get America/Chicago

If i do this in Firefox i just get undefined (for every location)

[mattjohnsonpint]

That is really bizarre. You should get Europe/Berlin for Germany, and Asia/Shanghai for China.

Are you on the current release of Chrome? Can you give me the result of navigator.userAgent in each?

Can you try to update and see if you still have the problem?

[mattjohnsonpint]

And again, what does printenv TZ show in the linux shell?

[philipp-serfling]

Oh sorry, i've overseen your comment about printenv TZ
No, i did override this. So the result is an empty string

navigator.userAgent
In Chrome:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36"

In FF
"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0"

Ubuntu version 16.04.2 and 17.04

This might be an issue of the Ubuntu though,
i have also tried with Chrome on Windows 10 and the results are as you expect
Europe/Berlin, Asia/Shanghai

[mattjohnsonpint]

Ok, so with the Intl API returning strange results, there's not a lot Moment-timezone can do... Still I want to dig deeper on this to see if I can figure out what's going on. I need to take the time to spin up some of this environment to try to reproduce your results. My guess is it has to do with ICU version. IDK if libicu is distributed independently or just with Chrome. I'll leave this open for now until I can figure it out.

[philipp-serfling]

It is no blocking issue for me, so that works perfectly fine.
Tell me, if i can help you with something.

Thank you very much for caring!

[avdv]

Hi, we run into the same issue. The problem is indeed a bug in libicu: http://bugs.icu-project.org/trac/ticket/12770

just my 2¢

[bolasblack]

I encountered this issue too, on Chrome 60, 61 for Mac, I found if I switch timezone to another timezone and then switch back, Intl.DateTimeFormat().resolvedOptions().timeZone will return the correct value, but new Date().getTimezoneOffset() will be 0. When I restart Chrome, timeZone became America/Chicago again.

Seems it only appeared when getTimezoneOffset() === -480, when I switch timezone to Asia/Tokyo and restart Chrome, the timeZone didn't change and the getTimezoneOffset() still -540...

[iffy]

A user of mine is encountering this same problem in an Electron app (I don't know what version of Chrome is uses).

thing	value
moment.tz.guess()	America/Chicago
moment.tz(guess).format()	2018-04-18T09:19:14-05:00
moment.utc().format()	2018-04-18T14:19:14Z
(new Date()).getTimezoneOffset()	-480
(new Date()).toString()	Wed Apr 18 2018 22:19:16 GMT+0800 (CST)
(new Date()).toLocaleString()	4/18/2018, 10:19:16 PM
moment.version	2.18.1

[maoqxxmm]

I have the same problem in QQBrowser. I'm in China. The user agent is
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.82 Safari/537.36 QQBrowser/4.0.4035.400

thing	value
moment.tz.guess()	America/Chicago
new Date().getTimezoneOffset()	-480
moment.version	2.6.0

[avdv]

Chrome/48.0.2564.82

If that's the correct version number, this is too old -- as it was released 2016-01-20.

AFAICS, QQBrowser's latest version is 10, which uses Chrome 63. Try to upgrade.

[marswong]

wrong time for CST. the CST time should be 8 hours later than UTC, but actually it performs 12 hours.

added: sorry, it seems to be a bug of the implementation of Date.getTimezoneOffset() in V8@6.2.414.54

[rafallyczkowski]

Since there is a single time offset in entire China
https://en.wikipedia.org/wiki/Time_in_China

when using moment library for different time zones (based on PHP entires) like:

{code}
moment.tz('2016-01-01', 'Asia/Shanghai').format('ZZ'),
moment.tz('2016-01-01', 'Asia/Urumqi').format('ZZ')
{code}

even though they should be UTC +8

there is +8:00 and +6:00 because of geo offset

[avdv]

@mbm-rafal this is a completely different problem, right? Would you please open a new issue?

[ccorcos]

I'm having this same issue with electron v2.0.5.

In Chrome, I get what I would expect.

> new Date()
Wed Apr 24 2019 07:54:56 GMT+0800 (Philippine Standard Time)

> Intl.DateTimeFormat().resolvedOptions()
{locale: "en-US", calendar: "gregory", numberingSystem: "latn", timeZone: "Asia/Manila", year: "numeric", …}calendar: "gregory"day: "numeric"locale: "en-US"month: "numeric"numberingSystem: "latn"timeZone: "Asia/Manila"year: "numeric"__proto__: Object

> moment.tz.guess()
"Asia/Manila"

However in Electron, it's wrong.

> new Date()
Wed Apr 24 2019 07:56:25 GMT+0800 (PST)

> Intl.DateTimeFormat().resolvedOptions()
{locale: "en-US", numberingSystem: "latn", calendar: "gregory", timeZone: "America/Los_Angeles", year: "numeric", …}calendar: "gregory"day: "numeric"locale: "en-US"month: "numeric"numberingSystem: "latn"timeZone: "America/Los_Angeles"year: "numeric"__proto__: Object

> moment.tz.guess()
"America/Los_Angeles"

The interesting thing is that the UTC offset is correct, but the timezone label is wrong.

If I skip this line and let moment do the timezone guessing, I actually get the correct timezone.

moment-timezone/moment-timezone.js

Line 337 in c377ac8

if (intlName && intlName.length > 3) {

Perhaps we should consider the native timezone logic unreliable, especially since what we're really after is UTC offsets for computing the correct dates...

I would like to just skip the native call to Intl.DateTimeFormat().resolvedOptions() entirely because it appears to be unreliable. However, maybe it gives more accurate time zones when it is correct. So maybe we should just to a sanity check if the UTC offset is consistent with the timezone and if not, fall through to the zone scoring logic. Date.getTimezoneOffset returns the correct value so I think this should work.

> (new Date()).getTimezoneOffset()
-480

[ccorcos]

OMG. Pacific Standard Time and Philippines Standard Time also have the same abbreviation -- PST!

[gaodeng]

any news?

[ichernev]

I don't think moment-timezone uses offset names (PST, CST) to determine which timezone you're in. It uses offsets (the numbers) of different dates, and tries to match that to existing timezones.

It's cool to debug libicu from moment-timezone, but not really the right place for it. Check #873 (comment)

If we had way to tell guess to not use Intl at least we could close issues that are based on buggy Intl support (and shield users from them...).