Egypt's UTC offset not accounted for in afterLoadData

[babofitos]

https://www.reddit.com/r/medicalschoolanki/comments/1k4luez/review_heatmap_bug/
There have been several users reporting here that their heatmap has no reviews for April 25.

I've replicated this bug by changing my OS to Egypt, Cairo time and can confirm the same pattern. The last Friday of each April after 2023 will have the heatmap for that day blank out.

I've looked at the add-on's code and can see why this is the case.

The add-on gets a timestamp and tries to convert it to UTC, but because of the transition to daylight savings, the offset given will actually give a date of Apr 24, 23:00 instead of the wanted Apr 25, 00:00.

Output of the timestamp before trying to convert to UTC:
1745539200 seconds, the timestamp in local time.

Converting to milliseconds, and giving us the date

new Date(1745539200 * 1000)
> Date Fri Apr 25 2025 03:00:00 GMT+0300 (Eastern European Summer Time)

getTimezoneOffset() gives -10800 seconds or 3 hours

1745539200 - 10800 = 1745528400 seconds, the timestamp in UTC.

Converting to milliseconds, giving us the wrong datetime by 1 hour because at 02:00, the offset should go back to being 2 hours.

new Date(1745528400 * 1000)
> Date Thu Apr 24 2025 23:00:00 GMT+0200 (Eastern European Standard Time)

We gain some evidence of this happening by looking at our reviews on April 24th. The review count for that day should be unusually high compared to other days, because our reviews for April 25 are being shifted over to the 24th.

Why only Egypt?

I've briefly tried to do some tests with American daylight savings and it looks like JavaScript correctly accounts for the shift:

var dstStart2025UTC = Date.UTC(2025, 2, 9, 6, 0, 0, 0); 
new Date(dstStart2025UTC).getTime() - new Date(dstStart2025UTC).getTimezoneOffset() * 60 * 1000
new Date(1741489200000)
> Date Sat Mar 08 2025 22:00:00 GMT-0500 (Eastern Standard Time)
var dstStart2025UTC = Date.UTC(2025, 2, 9, 7, 0, 0, 0); 
new Date(dstStart2025UTC).getTime() - new Date(dstStart2025UTC).getTimezoneOffset() * 60 * 1000
new Date(1741489200000)
> Date Sat Mar 08 2025 22:00:00 GMT-0500 (Eastern Standard Time)

I'm not sure why this is the case - maybe the runtime is simply not updated yet for Egypt's daylight savings.

Solutions:

1. Use an external library for handling the transition. This shouldn't be too bad, assuming this is the only place we have to handle the conversion to UTC and it would be a lot simpler than trying to update Cal-Heatmap to a newer version which already uses an external library to handle locale.
2. Hacky fix where we check if the user's timezone is Egypt, with something like

Intl.DateTimeFormat().resolvedOptions().timeZone;
> Africa/Cairo

and then we check if we're on the last Friday of April/last Thursday in October.

Unfortunately I can't make a PR as there are no build steps in the README ☹

[omarmohmansoor]

Hey, the issue is with all the UTC 2+ countries, not just Egypt.

[FishieTaco]

This is also an issue for Australia (for example, the heatmap is messed up october 4/5 2025) due to daylight savings. Oct 4 shows more reviews, Oct 5 shows none. Even after doing reviews on Oct 4 not all of them get displayed properly on the map.

[FishieTaco]

@babofitos do the build steps here assist in making a PR? #210

[Danika-Dakika]

For anyone who wants to share their data with the developer to help him work toward a solution -- see #151 .