Ventusky

Completely false data (Including the archive) for many places...

Your feedback and suggestions

Let's take Chicago, USA, for example, on February 16, 2026 (and February 18 as well). Chicago experienced a sudden warming.
People were jogging and relaxing in T-shirts, and the temperature was 60°F/15°C.

This is clearly visible in historical data on a bunch of weather websites.

None of your models or historical data for this location even comes close to showing the true temperature. And this is observed in many places.

It's also extremely bad that none of the models even show the water temperature in lakes and rivers.

It turns out that all the models are broken and display completely false data. Even historical data, which is already 100% known from real data and can be quickly adjusted.

What's the point of a service that offers historical data when it's completely false? And how can we trust current data if it completely disagrees with the real data?

Ventusky
It was my mistake, I figured out what the problem was. Unfortunately, your system (at least without a paid subscription) doesn't allow you to select a time zone in the settings. If a visitor is in a different region relative to the time at the desired point, you need to account for the time offset. Imagine a visitor from Europe, Asia, or even Australia. It's extremely difficult to see the desired readings at the desired time (especially in history), since your system simply assigns a time scale based on the visitor's IP address. And that's often not what they want! They want to see weather maps for a completely different time zone. They have to do some calculations in their head, which is extremely inconvenient. I recommend adding a time zone selection to the settings (even without a subscription) for calculating the time scale. Nowadays, many people around the world have begun to access the internet only through VPNs, and the exit point may be in a completely different place from where they actually are, which is even more confusing. It's better to have the time zone configured by the visitor themselves recorded in the cookie. They themselves decide which zone to base the time scale on. If they want to see the weather in Chicago, for example, but live in Europe, the simplest solution is obviously to set the time to the US time zone where Chicago is located, so that 6 PM in Chicago would be exactly 6 PM on your system's time scale.

I even came up with a way to make this more convenient for users. Add a special button next to or beside the timeline, or at the top, next to the settings icon, that will show the time on the timeline relative to the location visible at the center of the map (for example). If the Chicago metropolitan area is centered on the user's screen, for example, then their local time zone should obviously be used. If Tokyo is centered, then Tokyo time should be used. It's a bit more complicated when macro-scale is selected, but in that case, you can calculate based on the center of the screen display. Or, alternatively, make this configurable in the additional settings. Clearly specify the timeline's automatic alignment relative to what's shown on the screen.

But automatically shifting the timeline to the zone visible in the center of the screen is the most ideal solution, in my opinion, for all users. No need to rack your brains – the time on the screen is part of England, so it's automatically GMT. But if it's Australia, then it's Australian time.

Ventusky
Moderator
Ventusky

wtwt55
The time zone on the axis is the one set on your device. It is not determined by any IP address. Please check what time zone you have configured on your device.

It definitely cannot change based on moving around the map – that would make no sense. At any given moment, you can be viewing areas from all over the world.

Czechia

Your answer simply confirmed the obvious problem with viewing weather data in other regions, when the user wants a local time zone, not their own. Changing device settings is even more inconvenient (remember, this immediately disrupts all system logs and time relationships, meaning the time will be out of sync, which is strictly prohibited after the system has been installed and configured) than changing your website settings. Changing the time zone to a different one can instantly disrupt the order of messages in the system logs.

I previously suggested you simply monitor the weather in other regions relative to the user's location by checking a box to automatically adjust the time zone based on the center of the screen within their field of view. Or explicitly specifying the time zone in the settings. Users should NOT change their regional settings in the OS—this is incorrect, and your developers know this perfectly well.

Whether to implement my suggestion for improvement is, of course, your decision. Currently, the service is inconvenient for monitoring the weather in other regions, using a local time scale, because it might take a while to figure out that 6 PM local time doesn't necessarily mean 6 PM in another region, and doing such calculations in your head is no fun. Shouldn't a machine relieve humans of such mundane tasks? That's the point of automating any activity or service.

I still hope the development department's management will listen to me.

Please log in to add a post to the discussion.