onMount(() => {
    broadcast.on('redrawFinished', onRedrawFinished);
});

function onRedrawFinished(params: any)
{
	console.log('onRedrawFinished', params.path);
        _path = params.path;
	const dateString: string = _path.substring(0,4) + '-' + _path.substring(4,6) + '-' +   
        _path.substring(6,8) + 'T' + _path.substring(8,10) + ':00:00Z';
	_hour = new Date(dateString).getTime(); }

@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.

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 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.

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.

@Korina have the dev team looked at this yet?

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 using floor.