Feature Request - Allow manually setting timezone for Review Forecast

WaniKani Feedback
1

Problem: Firefox and other privacy respecting browsers have anti-fingerprinting measures that report out UTC timezone. While users can disable anti-fingerprinting, it also makes their privacy worse. In an age where surveillance capitalism is the norm, users shouldn’t have to compromise the privacy of their browser just for proper forecasting.

Solution: Have an optional setting that allows a user to set a timezone for forecasting. If set, forecast uses the set timezone instead of the timezone pulled from the browser.

Edit: Other Japanese studying resources like BunPro and Kistunio have this implemented if an example reference is desirable:

image

image

3 Likes
2

Out of curiosity, what measure is that? My main browser is Firefox Developer Edition, currently 102 beta 6

Users should know what UTC time it is though especially if they have a setting like that - it might be 15:50 here, but I know it’s 20:50 UTC

Anyways, WK doesn’t even respect 24-hour time settings or provide an option, so this should be directed to the userscript request thread

3 Likes
3

Fingerprinting Protection. Been in the browser for a number of years since they upstreamed it from Tor Browser alongside a few other things.

Not really? Not many people regularly deal with UTC based events. Guarantee you if you were to ask Firefox Wanikani users what the current time was in in UTC, 95% wouldn’t know.

That’s the point of requesting it here in Feedback … 3rd party scripts have no guarantees about being maintained and are subject to being broken due to API changes, etc. From a 1st party perspective it’s pretty easy to implement:

if(setTimezone != null)
  createForecast(setTimezone)
else
  createForecast()
1 Like
4

Yes, but it’s also even easier to implement 24-hour time in the review forecast from a first party perspective.

I’m trying to warn you ahead of time that it is not super likely to happen from a first party perspective

2 Likes
5

It’s not as easy as you might think btw, the WK team have a lot on their plate right now it seems, as far as I can tell, they are rethinking most parts of the review process to refine it. Besides you would need at least a place where you can set the timezone, probably in the settings, and you would need to store that in a database somewhere. Then this would be another place where bugs could appear from then on.

1 Like
6

Sure, but as a .NET webapps developer for a Fortune 50, adding a simple col to the UserProfileSettings DB table, tweaking the CreateUserProfile stored procedure to by default make timezone null, a SP to get/set timezone, and a timezone selector UI element on the existing settings page is about as basic as it gets from a developer complexity/requirements perspective. The logic is already there to create a Forecast based on a given timezone, all one is adding is an optional col to the UserProfileSettings table w/ basic get/set to make it user provided if desired instead of browser provided. The surface for new bugs is next to nil. There are two general cases: null or not null (and not null is a provided, selectable list, so users can’t provide bad inputs). And again, because the Forecast logic already exists, it’s just browser timezone based, the Forecast case handling should already exist if they have decent devs.

The real question is whether or not the ROI is justifiable for a day’s work on this given the small % of global Firefox/Librewolf/Tor Browser users, and what’s on WK’s current roadmap.

7

as far as I can tell, WK currently has 4 devs, so probably it’s not very justifiable

1 Like
8

Maybe. I’m guessing BunPro and Kitsunio both have fewer developer resources and a larger roadmap due to being newer though and yet they both have this feature because it’s very easy to implement:

image

image

9

Not sure about Kitsun, but Bunpro clearly is showing time zone dependent statistics that WK defers to userscripts (e.g. the Heatmap)

@Mods Could you give some cordial statement as usual?

10

“Review Forecast” is not a third party feature (userscript) that is time zone dependent, it’s an out of the box, first party feature that is time zone dependent, hence why I’m requesting the enhancement here in feedback and not a userscript that is time based thread:

It’s just that WK makes the assumption that the browser always reports the ‘correct’ timezone and I’m here reporting suggesting that WK like Bunpro and Kitsun have change that assumption given other threads have reported this as an issue in the past, but gotten the brush off by forum goers to disable privacy features such as:

https://community.wanikani.com/t/do-you-have-macos-uk-europe-timezone-issues/31160

Edit: It’s certainly possible though that WK could also make the user set timezone visible to userscripts to provide a better experience though, although this isn’t required for a minimal viable enhancement

11

Thanks for tagging us! I’ll bring this to the team’s attention :slight_smile:

6 Likes
12

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.