Hello, same problem here
Could you either send your API V2 key to me at kumi@kumirei.com (I wouldnāt need write access so if you want to generate a new one without it thatās cool) and/or put this localStorage.getItem('WKheatmapData1.7.0');
in your console and post here or email me the output? Since this is not happening to me I donāt really know what the issue could be.
This is pretty cool! Iāve been a crabigator since May 2016 so it doesnāt all show but I like how I can see where I got burnt out in 2017 with 1000ās of leeches and just quit. I came back 9 months later, reset to level 1 and am just now almost back at my previous level - but feeling much stronger this time around! Almost no leeches and usually only around 100 - 150 reviews a day. (I average 11 days per level)
That one lonely day in February 2018
Haha I just noticed that too! I think I opened a browser and did a couple of reviews but I wasnāt feeling it so I closed it out again.
You seem pretty consistent when youāre actually on the horse; thatās nice
I ended up sending you 2 emails, one with my token and another with the result. (Discourse didnāt allow me to post the result here)
Looking at the result, there was no data at all after 2019 April 1st, thatās weird. Iām guessing the token will help you more in finding whatās going on. All yours, thanks a lot!
Done, thanks!
@alihmd and @mrahhal Thank you for emailing me.
@mrahhal I only got your key, but I got both from @alihmd so thatās ok.
@alihmd The JSON you sent looks fine, and the data is being stored as it should. Even using your API-key I canāt replicate the issue.
@mrahhal Same with your API-key
Looking at the JSON I see that itās when DST started. However I donāt see any issue with the logic that uses the date to produce a timestamp for the heatmap (as I wouldnāt since it works for me).
I usually only test on Chrome; what browser are you two using?
I only use it on Chrome.
itās when DST started
Thatās the very first thought Iāve had too actually. What makes this weirder is that I and @alihmd actually live in the same area. Iām not sure whatās up with that. I canāt think of any other reason than DST, but youāre saying you double checked the logic there and it already works for you.
Maybe itās kinda related to our clock on our machines? If you want, you could tell me what function to call from your script, and Iāll try it out standalone on my machine to see if the results are being returned correctly.
Since the data is present thereās really only one function I can see being the culprit, unless itās an issue with the library creating the elements for the heatmap.
Itās this one, that converts the stored data to the format that the library wants.
// Transforms the data into the format the heatmaps needs
function days_to_timestamps(data) {
var heatmap_data = {};
for (var day in data) heatmap_data[Date.parse(data[day].date)/1000] = data[day].count;
return heatmap_data;
}
Basically it goes through all the days youāve studied, converts the ISO date Iāve stored in there to a unix timestamp in seconds, stores that in heatmap_data along with the number of reviews you did.
I see no reason for this to work for Mar 31 (ex 2019-03-31T10:00:00.000Z
) but not Apr 1 (ex 2019-04-01T09:00:00.000Z
) and onwards, as Date.parse("2019-04-01T09:00:00.000Z")/1000
would produce a correct unix timestamp.
Most likely Iām just overlooking something, but I have no idea what it might be. If you want to try and see if this is the problem then I suppose you could try
console.log(Date.parse("2019-03-31T10:00:00.000Z"))
console.log(Date.parse("2019-04-01T09:00:00.000Z"))
And see if thereās something wrong with the second output.
Iāll do some debugging on it later today, Iāll let you know what happens. Thanks.
Ehā¦ Thatās what I thought, the heatmap data is being produced correctly, but it seems like itās a problem with the heatmap lib, check those issues out:
- Any Idea why 19 october there is no rect? Ā· Issue #105 Ā· wa0x6e/cal-heatmap Ā· GitHub
- Parsing data leads to undefined index Ā· Issue #52 Ā· wa0x6e/cal-heatmap Ā· GitHub
Seems to me that DST related issues have not been resolved in the repo too. Ouch.
Doesnāt look like itās going to get resolved either. What timezone are you in?
Yeah.
My timezoneās standard name is āMiddle East Standard Timeā. Currently UTC+03:00 (DST active).
Now this renders the whole thing unusable. And the issue has been active since 2013, doesnāt look like itāll be resolved anytime soon. But I love your extension so much that Iām considering forking that lib just to solve this
I wonder if it can be solved by just putting the data on a different hour of the day. Maybe if you try adding an hour or two to the heatmap data through the function I mentioned earlier?
Tried a couple of things, I donāt know whatās going on anymore.
Tried replacing all DST dates with a consistent offset, same problem occurred. The data still looks good, problem is definitely somewhere in the lib. Double checked the timestamps too, they all look good. I dunno.
Hm. I figured that since it seems to work for most of us it might be possible for me to patch it by just offsetting, as the time of day the data is on doesnāt matter much.
With @MissMisc recent achievement of burning all wanikani review items, can we maybe add a special colour/icon/symbol for this?
You mean the last day of review (when the last item is burned) should have a different colour?