I see this as well. Not quite sure where the off-by-one error is, though.

I see this as well. Not quite sure where the off-by-one error is, though.

I'm having a sudden thought, could this be UTC related?
Currently all the dates/times are stored in UTC, and I think they still are
presented as such.

We'll need to think how to do that

I too had noticed this a few days ago but somehow now it is working fine and the heap map is plotting the contributions to the correct date, isn't it ?

Should we close this ticket then ? :)

the heap map is plotting the contributions to the correct date, isn't it ?

No it's not, cf the discussion above :)

Yes, I think it's due to timezone adjustments being applied to one but not the other, per https://pagure.io/pagure/issue/3019 .

I have a bit of time to look into this at present, as we're waiting for another Rawhide compose to inevitably blow up.

So, I've figured out the API endpoints are returning consistent data. I'm using my activity for 2018-02-18 / 2018-02-19 as the test case, here. The heat map on my user page shows "18 items on Sunday February 18, 2018" (and "4 items on Monday February 19, 2018"), but clicking on that dot shows "Activity on 2018-02-18 No activity recorded on that day".

The API endpoints used here are this one to generate the heat map, and these ones:

• 2018-02-18
• 2018-02-19

to generate the activity log for a specific date. The API data is consistent: the yearly summary reports a value of 18 for 2018-02-19 but no entry for 2018-02-18 (which obviously means 'no activity'), and indeed the daily log API link for 2018-02-18 gives nothing, while the link for 2018-02-19 shows 18 items.

So the bug here has to be in the code that takes the values from the user/(username)/activity/stats endpoint and turns them into the heatmap, somewhere. I think.

OK, so I think this is basically this upstream bug in the cal-heatmap library (fun fact: the version we are using is about four years out of date).

I think the best thing to do, if possible, would be to feed cal-heatmap data that's adjusted for local timezone...as we users probably actually do want this data to be relative to our local time, not UTC.

To link things up a bit more, the JS here hits the activity/stats endpoint with format=timestamp. That asks Pagure to give the dates in timestamp format. Pagure does this by getting the timestamp for 00:00 on the date in question, in GMT/UTC - which means it gets this for 2018-02-19:

"1518998400": 18,

and that's what is fed to cal-heatmap (it's a generic library - it can do heatmaps at all kinds of granularities - so it likes to just be fed timestamps and deal with converting them to hours and days and dates and things itself). But because cal-heatmap is operating in my local timezone, it decides that 1518998400 - which is Mon, 19 Feb 2018 00:00:00 GMT - falls on 2018-02-18 , because in my timezone, it does (that's the middle of the afternoon on 2018-02-18 in Pacific time), and draws the dot for '18 items' on 2018-02-18 instead of 2018-02-19.

So I think the heatmaps will be wrong any time the browser timezone is behind GMT, even by an hour. I don't think they'll ever be wrong if the browser timezone is ahead of GMT, because that would only break if the timezone was more than 24 hours ahead of GMT, and there aren't any of those.

An 'easy' fix here would be to just adjust the timestamps to local time before feeding them to cal-heatmap, but that would only mean we'd be showing correct information in both the heatmap and the list relative to UTC. I still don't think that's the ideal fix, as the user will be expecting to see the information relative to the browser timezone - if I made a change in the afternoon of 2018-02-18 my time, I want it to show up in the activity log for 2018-02-18, not 2018-02-19. So I think we need a way for the query to pass in the browser timezone offset and get timezone-adjusted data back from the API.

So I'm working on a fix for this, and I think I can do it, but it's not super straightforward, and I have to go to bed now. Will work on it more tomorrow my time.

https://pagure.io/pagure/pull-request/3027 should fix this. I tested it as hard as I could, with new unit tests and a local instance. Hope it'll work properly for everyone.

Commit f99ac7c fixes this issue