Search the Community
Showing results for tags 'timezone'.
Found 2 results
Dear Pete, this might not be the best forum for SimConnect questions, but this one might be an easy thing for you to get me some ideas on: SimConnect offers: CLOCK_SECONDS_ZERO CLOCK_HOURS_SET CLOCK_MINUTES_SET ZULU_HOURS_SET ZULU_MINUTES_SET ZULU_DAY_SET ZULU_YEAR_SET So, no way to set a local year and day here. To set a local date and time by setting the time part with the CLOCK_xx events and the date part with the ZULU_xx events might end up in a wrong resulting local date/time with an offset of +/- one hour in case the new date has a different daylight saving time and therefore a different timezone bias. Currently, I help myself in that I try to set the new time using the CLOCK_ and ZULU_ mix approach and afterwards I recheck the resulting local time against the wanted new local time. If they differ, I use the now updated "TIME ZONE OFFSET" variable I receive from SimConnect to update the zulu time, causing the sim to reload the scenery a second time, which is of course not nice. How are you dealing with this problem in your FSUIPC API? The whole problem seems to be around knowing the correct time zone bias for the current lat/lon and the desired date/time. I do not see how to get hold of this information other than asking some google web services and the like. Any ideas would be very much appreciated. Kind regards Walter
Hi, I get a lot out of STB, but one of the things I find a bit frustrating is that the timezone is always the FSX timezone. If I am flying from London to Kuwait, and I want to see the schedule of arrivals, all of the times are in the timezone that I am flying over, and not the time in Kuwait (even GMT would be better). It would be great if there was an option to ( a ) show the times as GMT and ( b ) show the times as the local times at the airport (and I guess ( c ) have the FSX time option for those that use that). The GMT function should be easy, because simconnect provides that data. The local times might be harder, but in implementations I've created for this problem, dividing the world into equal timezones is a decent enough approximation. You could call it 'approximate local time' :smile: Bryn