Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correct output of timezone ("z") for CET/CEST #1383

Open
vandres opened this issue Feb 13, 2021 · 5 comments · May be fixed by #1685
Open

Correct output of timezone ("z") for CET/CEST #1383

vandres opened this issue Feb 13, 2021 · 5 comments · May be fixed by #1685

Comments

@vandres
Copy link

vandres commented Feb 13, 2021

Describe the bug
When I am formatting the timzone with "z", I'll get a GMT+2. The date I am using is 2022-05-22, 11:00am UTC

dayjs(raceDate).locale(locale).format('LT z') // Output "13:00 GMT+2"

Expected behavior
I would expect CET or CEST. If I am using the long format instead, it works as expected:

dayjs(raceDate).locale(locale).format('LT zzz') // Output "13:00 Central European Summer Time"

Information

  • Day.js Version: 1.9.7
  • OS: iOS
  • Browser: Safari
  • Time zone: GMT+02:00 CEST
@vandres vandres changed the title Correct output of timezone Correct output of timezone ("z") for CET/CEST Feb 13, 2021
@iamkun
Copy link
Owner

iamkun commented Feb 13, 2021

This relies on the browser Intl result instead of Day.js.

@vandres
Copy link
Author

vandres commented Feb 15, 2021

@iamkun Thanks, I can see now.

@vandres vandres closed this as completed Feb 15, 2021
@vandres vandres reopened this Feb 15, 2021
@vandres
Copy link
Author

vandres commented Feb 15, 2021

@iamkun Maybe there is still an issues. See this code:

console.log(dayjs(raceDate).locale('de').format('LT z')); // Output "13:00 GMT+2"

console.log(new Intl.DateTimeFormat('de', {hour: '2-digit', minute: '2-digit', timeZoneName: 'short'}).format(new Date(Date.UTC(2021, 5, 8, 11, 0, 0)))); // Output "13:00 MESZ"

audiojames added a commit to audiojames/dayjs that referenced this issue May 26, 2021
Hard coding the locale here causes presumably unintended incorrect timezone formatting for users outside of the US.  Issue described in iamkun#1383, I propose removing the en-US in favour of the browser's default, or what is specified elsewhere.
@audiojames
Copy link

I also came across this same issue, it is caused by setting the locale of Intl.DateTimeFormat to en-US. PR #1499 addresses this.

@koooge
Copy link

koooge commented Jun 23, 2021

dupe? #1154

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants