Time slider on mobile is innacurate
-
When you drag the time slider to, say, 15:00, you may get shown the data for 15:00 or 16:00 depending on exactly how far you slide it. Looks like a basic rounding error to me where the data for the position of the slider is rounded to the nearest hour in two different ways, one for text display on the slider, and two to decide which data to display on the map.
Very easy to reproduce and has existed as long as I can remember using Windy, so I'm not sure why it hasn't been noticed by the developers unless there's something more subtle going on.
-
Just want to highlight this bug again. I forgot to say the mobile platform is Android. No idea about iPhone. Tested on two devices. This is a major bug. Windy is fantastic in general.
-
@jancellor Hello, could you attach a screenshot of this error? The data are shown for the next hour if it is for example 15:30 pm.
-
Sorry for the delay replying. I have attached a screenshot but the bug is very easy to reproduce without. Tested on two phones. Surely wrong every Android phone.
The image shows two screenshots which both say "13:00" on the time slider, but the data shown is different for both. To be clear, the model has not changed, nor anything else besides moving the time slider. The only difference is that the second image has the time slider moved towards the end of the hour.
Basically every time a user looks at a forecast in the future, there's a 50/50 chance the data displayed will be wrong. This is an enormous bug and probably very easy to fix. I would guess that the code for getting the time from the slider is duplicated in two places, one using
round, one usingfloor.
-
@jancellor Thank you for the report. Out dev team will take a closer look at it.
-
This is a huge bug. It exists on every Android device I've tried. It's very frustrating Windy have completely redesigned the interface but don't fix this very simple error.
@Korina have the dev team looked at this yet?
-
@jancellor Hi, I am not able to replicate this, can you provide any more screenshots with this issue from today?
-
@Ondřej-Šutera sorry I missed your reply. I have updated my notifications settings to email me so I shouldn't happen again.
I could provided another screenshot but I'm not sure it will help you replicate it. I have been using Windy several times per week for the last few years and this bug has always existed. It happens on every model for every layer for every part of the map. It happens on my phone (Pixel 3a) but also the one other Android phone I have tested it on so far (Oppo Find X5). My timezone is Europe/London in case that matters.
Is it possible that the time slider is doing some calculation based on screen width that is being unreliably calculated? (I know getting window dimenions in a browser/WebView can be error prone.)
What is definitely true is that the logic to determine what time to display on the time slider is not the same logic to determine what time of data to fetch and display on the map. Even if you can't reproduce, I would guess that you would be able to verify this in code.
How can I best help you investigate this further - provide more screenshots or a video, or get a list of more devices that are affected, or something else?
Version is currently 39.3.2.
-
Tested on a Pixel 8 Pro too. It is still buggy. It's the same on every device on every layer for any hour. 50% of all data ever shown on the Android app is wrong. I will repeat the reproduction steps. Slide the analogue time slider so that the time shows, say, "15:00" but the slider is closer to 14:00 than 16:00. The data shown is correct. Then slide the time slider by a few pixels so that the time still shows "15:00" but the slider is closer to 16:00. Now the data for 16:00 is shown.
@Suty if you can't reproduce this, the only thing I can think of is that something funny is going on with time zones. I am in the UK. Can you spoof your test device to UK or is there a dev in the UK you could assign this to?
This bug should be maximum priority. Half of all data shown is wrong, at least for all devices I have ever tested. Would you agree this is high priority? I understand it is difficult if not reproducible for some reason.
Thanks in advance for any time spent investigating this issue.
-
@jancellor Hi, I probably already understand the issue you have. You are right that sometimes the temperature changes a bit earlier than the hour on the timeline, but we still talk about pixels and it can be possible that the temperature is decreased earlier than in the whole hour. So I wouldn't consider this as a major bug, do you agree?
-
This post is deleted! -
@Suty sorry again for the late reply.
If you are experiencing the issue in the same way as me, no I don't agree the issue is minor. The time shown on the time slider must correspond to the data shown. If you slide the time until it says 4pm and it shows you the data for 5pm, it's simply wrong.
I wouldn't say it's an issue of pixels either. Programming wise, whatever code takes the position of the slider and rounds it to the nearest hour should be used both to determine what data to display and also to determine what time to show. It sounds like the same calculation is being done twice in two separate places with separate logic.
It would be great to see this fixed.
-
@Suty said in Time slider on mobile is innacurate:
@jancellor Hi, I probably already understand the issue you have. You are right that sometimes the temperature changes a bit earlier than the hour on the timeline, but we still talk about pixels and it can be possible that the temperature is decreased earlier than in the whole hour. So I wouldn't consider this as a major bug, do you agree?
Sorry but I don't understand this response at all. What do pixels have to do with it? Are you implying that the slider actually has greater granularity than full hours but this is not shown to the user?
I can reproduce the bug as James reports it on an S23+. The forecast for a given time varies between two values with a 50% chance of each.
It cannot be right that the forecast displayed for a given time rounded to the nearest has a 50% chance of being one value and a 50% chance of being another entirely different value.
