dayjs
dayjs copied to clipboard
Chrome v88 (88.0.4324.93) for Android does not recognize date
Device: Android phone (with Android v10) Browser: Chrome v88 (88.0.4324.93).
dayJs('2021-01-26T00:00:00Z').tz(tz) returns "Invalid Date". Started happening with Chrome upgrade v88.
dayJs(dateWithFormat).tz(tz)
--> Works everywhere except Chrome88 on Android 10
dayJs.tz(dateWithFormat, tz)
--> Works on Chrome 88 for Android 10.
Shouldn't these methods return the same values irrespective of the browser or the underlying OS?
According to the doc, timezone uses the browser built-in Intl API, which may have some uncontrolled change via different versions.
https://day.js.org/docs/en/timezone/timezone
I'll update to the Chrome v88 to see if there's something we could do.
@iamkun The more I dig, the more I find. The month and year is being swapped. so February 5th, becomes May 2nd. And this happens only on Android 10, Chrome v 88 only
I can confirm this issues All our users now see "Invalid date" :(
The issue is in the browser:
https://bugs.chromium.org/p/chromium/issues/detail?id=1169034&q=toLocaleString&can=2
Looks like chrome started to ignore locale in arguments
ECMA-402
Anybody found an alternative? or a fix for this?
I don't know about your use case, but we could exclude users with this specific Chrome version from adding the timezone.
This is only a hot fix for now, waiting for a proper fix.
Thanks @vdg437 , That's what we are thinking. But the problem is with historic data when day light saving was in effect. The day light saving dates will be messed up.
I wrote this polyfill to fix this issue. It is really ugly, but it should work.
// Chrome toLocaleString bug
(() => {
let testDate = new Date(2021, 0, 17, 20, 16, 51);
if (Intl?.DateTimeFormat != null) {
let str = testDate.toLocaleString('en-US');
if (str.indexOf('PM') == -1 || Number.isNaN(new Date(str).valueOf())) {
if (new Intl.DateTimeFormat('cs-CZ').formatToParts != null) {
let original = Date.prototype.toLocaleString;
Date.prototype.toLocaleString = function (locale, opts) {
if (locale != 'en-US' || opts == null || Object.keys(opts).length != 1) {
return original.call(this, locale, opts);
}
let format = new Intl.DateTimeFormat('cs-CZ', {
year: 'numeric',
month: 'numeric',
day: 'numeric',
hour: 'numeric',
minute: 'numeric',
second: 'numeric',
hour12: false,
timeZone: opts.timeZone
});
let parts = format.formatToParts(this);
let component = (type) => {
return parseInt(parts.filter(x => x.type == type)[0].value, 10);
};
return new Date(component('year'), component('month') - 1, component('day'), component('hour'), component('minute'), component('second')).toISOString();
};
}
}
}
})();
Notice: This code is only usable if you do not use "toLocaleString" anywhere, except dayjs. It just fix dayjs, but can break other code (if it use toLocaleString method).
Can confirm it's happening in Chrome 88 on Android 5 too
https://medium.com/hungryhub-tech/fix-weird-javascript-date-bug-on-chrome-android-e52e494c0835 thanks @janousek
@saiqulhaq There is one important problem with your polyfill. It does not work with timezone conversion. That is the reason why is my polyfill so ugly (it works with time zones).
I use dayjs timezone plugin currently But I don't know, does it have correlation or not However it's need to be fixed Thanks for the feedback
@saiqulhaq Take a look on this line: https://github.com/iamkun/dayjs/blob/2ab64ac3e84375e167fe1b23cb2282c9fdb5c930/src/plugin/timezone/index.js#L99 "toLocaleString" receive target timezone. But you are not working with it in your polyfill.
also have issue
any update on this?
Updates should be monitored in Chromium repo :) @badlamer added link. Here it is again: https://bugs.chromium.org/p/chromium/issues/detail?id=1169034&q=toLocaleString&can=2
As i see, bug is confirmed and even localized. So maybe soon it will be fixed.
Imho, right now, the best workaround is to detect chrome v88 browser and slightly modify toLocaleString
Seeing the same issue on Chrome 88 Android 10 only:
this code:
var now = dayjs().tz(timezone)
returns NaN
only on this browser.
Same exact Chrome build as reported when this issue was opened.
Same issue on Chrome 91.0.4472.120
Any permanent fix for this yet?
Seems like this issue occurs on android for other similiar packages (i.e. - date-fns
)
any progress on this issue? I'm facing the same issue
@janousek Thanks a lot...the tz
function works properly with your polyfill.
My issue seems to be familiar but the issue isn't there once I start debugging the react-native-app in Android. Advanced Formatting zzz
giving back 'Asia/Kolkata' instead of Indian Standard Time when debugger is off in Android too.
Also the android version is 12
and Chrome version 91
dayjs(timeStamp, "YYYY-MM-DD").format("MMM-DD-YYYY");
This helped me to solve the invalid date issue.