Invalid Date displayed on UI

[nylocx]

⚠️ Please verify that this bug has NOT been raised before.

• I checked and didn't find similar issue

🛡️ Security Policy

• I agree to have read this project Security Policy

Description

I just noticed that I have this display errors in the UI:

I tried to look into the DB but the datestamps look alright:

sqlite> select * from heartbeat limit 10;
1|1|1|1|200 - OK|2022-09-12 08:19:02.186|223|0|0
2|0|1|1|200 - OK|2022-09-12 08:20:02.420|174|60|0
3|0|1|1|200 - OK|2022-09-12 08:21:02.602|164|60|0
4|0|1|1|200 - OK|2022-09-12 08:22:02.774|199|60|0
5|0|1|1|200 - OK|2022-09-12 08:23:02.982|270|60|0
6|0|1|1|200 - OK|2022-09-12 08:24:03.262|324|60|0
7|0|1|1|200 - OK|2022-09-12 08:25:03.595|190|60|0
8|0|1|1|200 - OK|2022-09-12 08:26:03.796|189|60|0
9|0|1|1|200 - OK|2022-09-12 08:27:03.994|205|60|0
10|0|1|1|200 - OK|2022-09-12 08:28:04.210|152|60|0

Kind regards,
Alex

👟 Reproduction steps

Just started with docker-compose without any specialties.

👀 Expected behavior

The UI should show the correct timestamps

😓 Actual Behavior

All timestamps show Invalid Date

🐻 Uptime-Kuma Version

1.18.5

💻 Operating System and Arch

Ubuntu 20.04

🌐 Browser

Chromium

🐋 Docker Version

Docker version 20.10.20, build 9fdeb9c

🟩 NodeJS Version

No response

📝 Relevant log output

No response

[louislam]

It seems to be a frontend issue of dayjs.

• Could you provide more details of client side (browser version, linux desktop environment, language etc.)
• Try another browser on the same machine
• Try on your mobile phone

[nylocx]

Hi, sure, it really seems to be an frontend issue.

I use Chromium (from the default Arch Linux repository):
Version 107.0.5304.110 (Offizieller Build) Arch Linux (64-Bit)

My desktop environment is i3 on X11 with de_DE locales.
In Firefox on the same machine it renders just fine.

There are no errors or warnings in the browser console. I also tests with all plugins disabled in an "Inkognito"-Chromium with the same result. Do you need more information to debug this?

[louislam]

Tested on Ubuntu's Chromium, it is OK.

Can you also try in a new Chromium profile or incognito mode. Make sure it is not affected by any Chrome extensions.

I can't test on Arch Linux yet, because I found that the arch linux installation is too complicated for me and I don't have much time to read them. Are there any one-click-install for noob to boot it up quickly?

[nylocx]

Thanks for your time and effort

I can't test on Arch Linux yet, because I found that the arch linux installation is too complicated for me

Yeah I know Arch is a bit "complicated" to install and configure, but I switched from gentoo a few years ago, so this is all relative ;).

If you want to try an Arch based distribution with more plug and play setup try Manjaro Linux, should be up and running in no time ;).

https://download.manjaro.org/kde/21.3.7/manjaro-kde-21.3.7-220816-linux515.iso

I testes it even further
with LANG=C LANGUAGE=en_US,en chromium --incognito --lang=en_US,en --user-data-dir=tmp
which should be as base chromium as it can get I get this invalid date behavior:

But I tried google-chrome and firefox and both are fine, so it really seems to be the Arch Linux build of Chromium.

I just started up a Manjaro VM to check if the behavior exists there too. I will report back as soon as I have the results.

[nylocx]

Ok, I just checked with Manjaro and I get the same behavior as on my System. This was a clean Manjaro VM with German locales and Europ/Berlin timezone.

[Hahlh]

Can confirm this happening on my install of Manjaro with Chromium as well.
Same behavior with a clients site though, so this might not be limited to Uptime Kuma.

[louislam]

Spent some time on it and my conclusion is it is a bug of Chromium of Arch Linux.

The problem is toLocaleString() of Date.

let target = (new Date()).toLocaleString('en-US', { timeZone: 'America/New_York' })

It returns:

'11/21/2022, 3:15:58 PM'     // Arch Linux's Chromium 
'11/21/2022, 3:15:58 PM'    // Chrome on Windows or Firefox

When it pass to new Date()

new Date('11/21/2022, 3:15:58 PM') // Invalid Date
new Date('11/21/2022, 3:15:58 PM') // Date Mon Nov 21 2022 15:15:58 GMT+0800 (China Standard Time)

Still can't spot the diff? Let's check in hex:

27 31 31 2f 32 31 2f 32 30 32 32 2c 20 33 3a 31 35 3a 35 38 e2 80 af 50 4d 27 
27 31 31 2f 32 31 2f 32 30 32 32 2c 20 33 3a 31 35 3a 35 38 20       50 4d 27 

Omg, what is e2 80 af? Seems like another space character.

Since it is OK on Windows and Ubuntu, I think it is only affected Arch Linux's Chromium. You should report to them.

[louislam]

The person who decided to create so many space characters and the no-width character should be put in jail honestly.

It is not the first time that create a trouble for me and it is not the last time too I believe.

[nylocx]

Wao thanks for that, I will report Upstream and to the Arch devs.
The character is a https://www.compart.com/en/unicode/U+202F so a non breaking small space. Semantically this makes totally sense, but from a coder point of view I totally get why this is …, lets call it problematic ;). I guess there is some configuration locale default that has a format string set to this, as Archlinux is very close to upstream it might happen on other distros and OS's too once the dependency that causes this is updated. So really nice you found this early. From my point of view you can close this issue, I will refer to it in the upstream reports.

[lo48576]

This happens in my env both on uptime-kuma and on browser console, by Firefox 107.0.1 (64 bits) on Gentoo Linux.
So I think this is not Chromium- or Arch- specific...

[lo48576]

Not sure this is relevant so I'm sorry if this is not related, but FYI: reproducible on Node.js v18.12.1.
A space between 8 and A was U+202F (e2 80 af), same as #2318 (comment).

[louislam]

Not sure this is relevant so I'm sorry if this is not related, but FYI: reproducible on Node.js v18.12.1. A space between 8 and A was U+202F (e2 80 af), same as #2318 (comment).

Firefox 107.0.1 (64 bits) on Windows cannot reproduce.

I guess it may be caused by a Linux library or compiler on Linux. But yeah, I have no idea where I should report to.

[lo48576]

I guess it may be caused by a Linux library or compiler on Linux.

Thanks for the hint!
Arch and Gentoo are rolling release, and Firefox and Chromium uses node.js IIRC, so I googled and I think I found the cause: nodejs/node#45171 and nodejs/node#45753.

I guess the environment with this problem (including you and me) have ICU 72.1 installed and browsers are using it.
The issues are closed and the fix will be released eventually (maybe with Node.js v19.2.0?).

[louislam]

@lo48576 Thanks for your info.

In many formatting patterns, ASCII spaces are replaced with Unicode spaces (e.g., a "thin space").

https://icu.unicode.org/download/72

Turn out, it is a feature, not a bug, lol

Let see if dayjs is going to fix it, if not, I will handle it in Uptime Kuma. Reopen it first.

[louislam]

I just decided to fix it in Uptime Kuma first by copying the timezone plugin from dayjs.