Local time weirdness

FlightGear Flight Simulator: free open-source multiplatform flight sim

Brought to you by: curt, jmturner, stuartbuchanan, torstendreyer

#2499 Local time weirdness

Milestone: 2020.3

Status: New

Owner: nobody

Labels: None

Priority: High

Updated: 2021-03-08

Created: 2021-01-01

Creator: Sidi Liang

Private: No

The local time in Beijing(ZBAA) and the surrounding areas is 1 hour faster than it should be. Some other places in the same timezone (UTC+8), for example Singapore, Shanghai and Chengdu have the correct local time.

Also, resyncing the timezone files from my system doesn't change anything, and it used to be correct in ZBAA so shouldn't be a timezone file issue.

I'm not sure when this is started to be wrong, I noticed this issue today.

Discussion

Sidi Liang - 2021-01-01

Oh I forgot to mention, it seems that this is not related to the operating system. Both macOS and Windows has this problem.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2021-01-01

Here on Arch Linux, Local time is just empty in the time dialog. Even if I rm -rf Timezone&& cp -r /usr/share/zoneinfo Timezone

Last edit: Anonymous 2021-01-01

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2021-01-10

Screenshot of time dialog on next

Last edit: Anonymous 2021-01-10

210110-125105.jpg

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2021-01-10

And it turns out that on 2018.3.6 it was working: time in LOWI was correct.

210110-125544.jpg

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

James Turner - 2021-01-10

Okay, so next step would be a bit of manual bi-secting to figure out when it broke; I guess start with middle of 2019, or January 2020, and work from there. If we can get to within a month or two, hopefully the commit will be obvious by inspection.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2021-01-10

And now after having ran 2018.3, Local works in all subsequent versions including next. This is strange...

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

James Turner - 2021-01-10

Oh weird: can you remove your autosave.xml and see if it breaks again?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2021-01-10

Turns out that it's not autosave. I narrowed it down to the following: "version >= 2020.3 AND using launcher"

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

James Turner - 2021-01-10

Okay, is this launcher passing any time arguments? (check with Ctrl-L) It should only pass any time-related stuff if you've made explicit settings in the 'Environment' page, either to set a time of day (morning, evening, etc) or an explicit time+date.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2021-01-10

Looks like there is nothing time-related.

I could narrow it down further to --launcher --language=ru, which seems to agree with recent post on ML that it's locale problem.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2021-01-12

I'm taking the issue with launcher to https://sourceforge.net/p/flightgear/codetickets/2514/ because it seems unrelated to this. Sorry about the intrusion.

Last edit: Anonymous 2021-01-12

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sidi Liang - 2021-03-08

Reposting my last email in the list here:

Hi all,

After some brief reading to the code, I assume that FG uses the position coordinate to find the nearest Timezone coordinate defined in zone.tab file. Is this correct? If so, this might explain why we have this problem: Pyongyang and Seoul timezones are both UTC+9 (instead of UTC+8) and they both have a shorter distance than Shanghai, which coordinate is used for Beijing time in zone.tab file.

I tested this by commenting out the lines for Pyongyang and Seoul in the zone.tab file which FG uses, and I did managed to get the correct time for Beijing.

So, if my assumption is correct, it's a good news as we have a clue now though it can't explain why nobody noticed this issue before. And the fix would be... complicated, as finding the nearest timezone coordinate just simply won't work for Beijing (and maybe some other areas with the same problem)?

Kind regards,
Sidi

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Log in to post a comment.