According to the SU16 changelogs, the time zones were said to be updated to be more accurate. However, when I checked Madeira and Arizona when I updated to SU16, they were still shown to be UTC-2 and UTC-6 respectively when it should be UTC+1 (Madeira is in DST) and UTC-7 respectively (Arizona is UTC-7 all year around)
Okay, so the time slider in FS2020 has been broken since SU14 or so, where the local time / UTC time are always the same regardless of the area of the world you are in.
At first glance, this is fixed in SU16. But under specific conditions, the old “Local time always equals UTC time” bug returns. Here’s how:
After starting FS2020, select Free Flight and enter YPMQ as the starting airport. The current AEST and UTC times will be correct:
Use the slider to adjust the local time of day, and note that the UTC time correctly adjusts along with it.
Now start the flight. In my case, the flight actually loaded at 3:05 AM AEST, eg in the middle of the night, instead of what should have been 1:05 PM AEST / 3:05 AM UTC. (In other words, SU16 is incorrectly using the UTC hour-minute values as the local time.)
Next, correct the local time to 1 PM so you can fly in daylight as desired.
End flight by returning to the main menu
Return to the free flight / world map screen. Note that while the “select departure” option is now blank, the map has retained its original position and is still showing the YPMQ airport. In spite of this (and because no departure airport is selected) the clock is now confusingly ignoring the on-screen local YPMQ time and is showing the UTC time twice.
Recommendation: If no departure / arrival airports are selected, and the map zoom level is <10NM, the time slider should default to showing the current local time matching the center of the on-screen map.
And also fix the flight loading time to correctly match the local time hour:minute values instead of UTC hour:minute values (unless, of course, the flight is starting within the UTC timezone)
2 Likes
I’m glad I’m not the only one who noticed that the time slider would reset itself to UTC regardless of the timezone of the chosen spawn point on the world map; I would also very much like to see this fixed, as it’s mildly annoying.
1 Like
it seems long unreperable bug in row with failure setting resetting triggers time… 
So with 1.39.2.0 I note that the “time of flight” selection appears to be fixed. If I select a Sydney departure time of 1:03 pm local (3:03 am UTC) the flight now loads with the expected local clock time of 1:08 pm and afternoon sunshine. It’s lost 5 minutes somewhere (1:08 pm vs 1:03 pm) but it’s close enough.
But when I exit to main menu and return to the world map, the time (and map colouring) still defaults to real-time mode, with a starting point somewhere that is now UTC+1 for some reason (where both used to be UTC before) with Sydney airport back in darkness.
I have to select a local departure point again, and re-adjust the local time back to what I had selected before, to get Sydney airport in daylight again, with the correct local and UTC values showing.
i live in AZ, i really hate seeing that i have revert -1 or +1 depending on the time of year. we are lazy here and dont change clocks..hope to see season implimented in 2020 while 2024 gets vram solved and issues as well as 2020 getting correct timezones
@CrankierCobra32, based on the reactions to how seasons are currently implemented in FS2024, I’m glad they haven’t duplicated that approach in FS2020. Just search this forum for “brown grass” as an example. So I’m hoping they keep FS2020 “seasonless” for the moment. Even though FS2020 was SUPPOSED to have seasons, I suspect that if/when they manage to improve the season-implementation method in FS2024, it will likely remain a FS2024-only feature.
1 Like