See the screenshot attached.

When the time in the ATIS changed on the first day of a month, the age calculation was not able to handle that and overflows to some large number.

Just noticed that this is still happening (and it's happening right now since we are at the end of month again...).

Looking at the code, it seems that the issue comes directly from the server side. The server returns a ux: null in the trend array after metar which is why all the wrong time have exactly the same value, howOld treated it as 0... The returned time is in fact the time since Unix epoch....

Strange... I saw this everywhere except on Android (phone, both the app and chromium) that uses a different UI.

Places I could reproduce this includes (all over a few versions in the past year),

Linux Desktop: Chromium, Firefox
IPad (mini 5): The app, Chromium, Safari

The screenshot is from the ipad app.

The time difference may be confusing sometimes (I was confused by AM/PM just now a few times when trying to reproduce it) so you may need to drag it left and right a few times to see.

See screen shot below.

When showing the ten day forecast, the thin bar for selecting the time shown on map gets out of sync with the local weather display below it. The time selection seems to be still using the same time scale as the 6 day forecast. This makes it very confusing to figure out if the currently shown weather on the map is actually the one corresponding to the time I care about, especially since the date isn’t shown. It also makes it, afaict, impossible to select a map time that is ten days in the future since the time selection bar run out of time....

This bug does not affect the android phone app since it uses a different ui. It seems to have appeared about a few months ago.

See the screenshot attached.

When the time in the ATIS changed on the first day of a month, the age calculation was not able to handle that and overflows to some large number.

Hi,

When showing a value with a unit of length (e.g. cloud base or visibility), I very often get numbers that doesn't seem right (like a visibility of 20sm in a rain) and indeed are always much larger than the real value. Looking at the code it seems that the input to Picker.createHTML is likely the correct number in imperial unit though the conversion functions conv.ft.conversion and conv.m.conversion both assume that the input is in metric unit (the one used for cloud base is a for meters and 3.28 * a for feet). This causes the number shown for cloud base to be off by 3.28, which easily makes the difference between VFR and IFR....
I did not check all other units. They could have the same issue but is much harder to verify for me.

This issue could be locale/setting dependent since my browser's locale is zh-CN, which uses metric unit. I also want to say it didn't used to be an issue when I first found this in early January this year but only starts to happen a month or two after that (in case this helps locating the code upgrade that triggers the issue....).