Invalid Date displayed on UI

This issue has been tracked since 2022-11-15.

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

  • I checked and didn't find similar issue

🛡️ Security Policy


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,

👟 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


💻 Operating System and Arch

Ubuntu 20.04

🌐 Browser


🐋 Docker Version

Docker version 20.10.20, build 9fdeb9c

🟩 NodeJS Version

No response

📝 Relevant log output

No response

louislam wrote this answer on 2022-11-23

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 wrote this answer on 2022-11-23

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 wrote this answer on 2022-11-23

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 wrote this answer on 2022-11-23

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 ;).

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 wrote this answer on 2022-11-23

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 wrote this answer on 2022-11-23

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 wrote this answer on 2022-11-23

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 wrote this answer on 2022-11-23

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 wrote this answer on 2022-11-25

Wao thanks for that, I will report Upstream and to the Arch devs.
The character is a 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.

More Details About Repo
Owner Name louislam
Repo Name uptime-kuma
Full Name louislam/uptime-kuma
Language JavaScript
Created Date 2021-07-03
Updated Date 2022-11-30
Star Count 23666
Watcher Count 159
Fork Count 1992
Issue Count 694


Issue Title Created Date Updated Date