Today / Last 24 Hours Not Rendering

[wgmyers]

In my local umami install (1.23.0), no data appears on any chart when set for 'today' or 'last 24 hours', despite there being a non-zero number of visits. All other time periods display as expected.

This occurs on both Firefox and Chrome in Linux, and on Firefox, Chrome and Edge in Windows.

The lines appear to start rendering but then fade to nothing.

Logging out and in again makes no difference, nor does force reload or close / restart browser.

Not sure how long this has been going on since I've not looked at this view in a while.

[eikeschott]

Was just about to open the same issue, I'm experiencing the same issues as described above.

I think this might have to do with the recent time change from summer to winter-time in the EU. Clocks were set back one hour last night and I think this might have screwed over some of the queries that are being made to fetch data from the database.

Opening F12 and reloading the page with "Last 24 hours" selected gives some insight into that.
There is a failed request on each page reload stating:
GET https://redacted.domain/api/website/2/events?start_at=1635613200000&end_at=1635699599999&unit=hour&tz=Europe%2FBerlin net::ERR_BLOCKED_BY_CLIENT

Converting epoch times back to readable time using epochconverter shows the start date at:

and the end date at:

For the "Today" tab the request looks like this:
GET https://redacted.domain/api/website/2/events?start_at=1635631200000&end_at=1635721199999&unit=hour&tz=Europe%2FBerlin net::ERR_BLOCKED_BY_CLIENT
Start Date:

End Date:

I can confirm the graphs were working as expected yesterday, so before the time change to winter time happened in the EU.

Running date inside the database and the umami container returns the date one hour in the past.
When mounting /etc/localtime:/etc/localtime:ro to both the database and the umami containers, and rebuilding both the date command returns the correct date but the graphs are still broken.

Hope I was able to provide some useful information. If I can do any further testing please let me know!

[wgmyers]

Thanks, Eike. I too am in Europe (UK) and so am also within 24 hours of a summer/winter time change.

Since I have no events set up I cannot reproduce the failed GET on events.

However, I did look at the GETs for pageviews (when set to Today / Last 24 hours) - both settings succeed for me and do seem to contain data; it's just that the data fails to render.

This may explain the 'lines appear to start rendering but fade to nothing' behaviour I am seeing, and would point to this part of the issue lying somewhere in the rendering code.

It seems likely that the problem will appear to go away (at least in Europe) some time overnight, when the earlier bound of the 'last 24 hours'/'today' thing is once again in the same TZ as the later one.

[wgmyers]

FWIW, here is a screenshot of one of my empty barcharts:

The (somewhat pathetically tiny) figures at the top indicate that the chart is receiving data.

But the times are rendered thus:

... 00:00 | 01:00 | 02:00 | 03:00 | 04:00 ...

However, due to the summer/winter time change, 2am happened twice last night, so we should ideally see something like:

... 00:00 | 01:00 | 02:00 | 02:00 | 03:00 ...

Perhaps this is causing the left-hand side of each bar to be rendered at the same place as the right hand side, somehow, leading to zero width bars. Maybe, during the corresponding winter->summer time change, we see double width bars instead.

Unfortunately, looking at components/metrics/BarChart.js, all the actual drawing stuff seems to happen over in chart.js, with which I am not familiar. Could the bug actually be upstream?

[rosscdh]

+1 can confirm same issue

[eikeschott]

It seems likely that the problem will appear to go away (at least in Europe) some time overnight

@wgmyers This is the case for me. Graphs are displayed normally again.

[wgmyers]

@eikeschott Same here.

However, there is an upcoming DST change in US / Canada on Sunday November 7th :)

Looking through chart.js issues, I found this, which may be relevant here: chartjs/Chart.js#6548 - essentially the chart.js folk don't touch TZ / DST stuff and leave it to your chosen date library (moment / luxon / etc). So the bug may be even further upstream :(

[mikecao]

This seems to always happen around DST time changes. Would love if someone could figure it out.

[wgmyers]

Dug a bit more and found lib/date.js which seems to be where the data array is calculated for charts. Looks like the x-axis data of charts is being calculated in umami after all?

There's a getLocalTime function there, but I can't see where it is called, if anywhere.

Generally, the assumption is reasonably made that the locale of the first item in the data array is always the same as the last. This is (hopefully) true, but on DST change days, the call to getTimeZoneOffset inside getLocalTime will return different offset values for each.

Something clever that I don't entirely follow happens in getDateArray, which I think returns the array of individual x-axis labels for charts. If so, and since that function already takes startDate, endDate and unit as parameters, then in the case that unit is hours, maybe it should first test to see whether getTimeZoneOffset was the same for the start and end dates, and if not, calculate and apply it for each item in the returned array, rather than, as currently, applying no time zone offset.

I'm also unsure about the correct value of n (line 133) for that case, since there should (maybe) be an extra item when the clocks go back and one less when the clocks go forward and it's not clear what currently happens, since the code assumes that each item is human-readably an hour apart, which isn't the case on DST change days.

The question then becomes - how does chart.js handle a correctly formed data array for a 24 hour period including a DST change. But we know it misbehaves when such an array is simply sequential.

Apologies that I am unable at the moment to go ahead and attempt to write a patch for this - if I can find time, I will try but hopefully someone else already set up for hacking on umami will find the above useful?

On which note, there's an npm package called "chronokinesis" which I've used elsewhere to provide mock times for testing this kind of code, including around DST changes.

[razinj]

I believe the issue still persists, I even looked at Umami's live demo and It's the same as my instance.
Any idea how to solve this / or what is the issue exactly?

Both my Umami and DB instances are reporting the correct time/date for my timezone.
I updated to v1.28, the same issue.

EDIT: For some reason, I can see the bars now, the only change was that I restarted my machine, maybe it's related.

[abe-winter]

uhhh no idea if I'm running into the same thing, but today is the DST transition in the US and my hourly chart is weird: it loads, but animates from super-wide to invisibly narrow in under a second

(^ that's the hourly chart which is broken. The daily chart seems fine)

the chart bars seem correct, they just vanish

I've attached screenshots from this animation

if this is a twice-a-year issue for DST which is going away in some places anyway, I don't mean to steal dev attention -- just raising in case useful

also happy to do work on this if it's helpful

[abe-winter]

update: fixed itself after midnight

[zhawtof]

Not sure if this is related as this discussion is quite old, but I ran into the dashboard not working. If you run also run across this, it seemed an import of moment-timezone was messing this up for me #2395.