dayjs

dayjs copied to clipboard

Describe the bug I have dates formatted in ISO-8601 format and use dayjs to convert them to different timezones. Conversion works file for all cases except for "Europe/London". It seems the issue might apply to all timezones that match UTC one.

What i do is i use dayjs in an angular app where i have a custom pipe doing the following in the function:

dayjs.extend(utc);
dayjs.extend(timezone);
return dayjs(value).tz(tz).locale(locale).format(pattern);

where value is 2020-11-06T19:27:08Z and tz Europe/London and pattern DD MMM, HH:mm a

In this case i would expect 06 Nov, 19:27 pm but i get 06 Nov, 17:27 pm. If i change timezone to something that does not match UTC like Europe/Athens or Europe/Paris the conversion works fine.

Information

• Day.js Version 1.9.6
• OS: [e.g. iOS]
• Browser Chrome/Firefox

Looks ok. https://runkit.com/embed/2p2231hs3lji

Indeed it does @iamkun. Weird that the exact same code in my app does not work the same and that it is specific for "Europe/London" only. I am most probably missing something on my side. Will close the issue for now and check again what is happening on my end. If i get something interesting i will post it for future reference. Thanks a lot.

Ok managed to get a better view on why this is happening. Problem seems to be timezone with locale usage. Check this link https://runkit.com/embed/gaitj4v88l8d

If i put .locale() call after .timezone() call i get the issue. If i put .locale() call before .timezone() call i get the correct time, but output is not localized based on locale. This is easier to verify with the greek locale el.

Hi @anzap, I have the same issue. It's showing the wrong time but only for UTC-ish timezones like Europe/London and Europe/Dublin. Can this issue please be reopened? Or, @anzap, can you create a new one with your input and runkit example?

@AlexGrafe it is already reopened. I also got a workaround to work in my case, and even though it is very ugly and most probably non-performant, it can help as a temporary solution till this is fixed. Solution is to first convert to appropriate timezone and then to string. Then parse the string and print out with appropriate locale. See last example in this link https://runkit.com/embed/izgfo00kpis9

Thanks @anzap. Everything works with enough duct tape I guess. Thanks for the workaround 👍

You just saved my night, thanks @anzap

@iamkun Any update on this one?

This is still an issue with the latest update. This is a significant bug with the locale() function right? Basically what its doing is its marking any date that's in timezone +0 as UTC when locale() is called. At least that's what it seems to be doing... Can someone look into this?

Timezone seems broken for London in general. It keeps adding my timezone locale. Very frustating.

console.log(dayjs.tz(new Date(), "Europe/London").month(1).startOf('month').format())
2022-02-01T05:00:00Z

Anyone find any fix to this?

Is there anyone looking into this? Need locale and timezone to work before publishing my app, and I imagine it's not an uncommon scenario.

@iamkun I think this reproduces the issue as I've seen it: https://runkit.com/bingnz/dayjs-london-bug

I have same problem too.

I have same problem. I recommended this in my company and moved here because of small size. but facing issue here also

This problem exists for the following time zones with UTC +00:00. [ 'Africa/Abidjan', 'Africa/Accra', 'Africa/Bamako', 'Africa/Banjul', 'Africa/Bissau', 'Africa/Conakry', 'Africa/Dakar', 'Africa/Freetown', 'Africa/Lome', 'Africa/Monrovia', 'Africa/Nouakchott', 'Africa/Ouagadougou', 'Africa/Sao_Tome', 'America/Danmarkshavn', 'Antarctica/Troll', 'Atlantic/Canary', 'Atlantic/Faroe', 'Atlantic/Madeira', 'Atlantic/Reykjavik', 'Atlantic/St_Helena', 'Europe/Dublin', 'Europe/Guernsey', 'Europe/Isle_of_Man', 'Europe/Jersey', 'Europe/Lisbon', 'Europe/London' ]

@iamkun this issue still persists in the latest release.

I've created a codesandbox reproducing the issue, it occurs when calling startOf/endOf/add/subtract with a dayjs date using a tz in GMT-0. https://codesandbox.io/p/sandbox/new-grass-hfmczy I provided equivalent moment-timezone examples to show the expected output.