Time related simvars are mixed up

Version: 1.1.7.0

Frequency: Consistently

Severity: Low

Context: Global issue as far as I can tell, affects all addons and all APIs (WASM, XML, HTML, Simconnect)

Bug description:
Time related simvars show wrong data:

E:LOCAL TIME instead of local time returns in-game UTC time
E:ZULU TIME instead of in-game UTC time returns host computer UTC time. It’s not affected by sim time setting at all.

Date simvars in 2024 also show Windows date and not the date set in the simulator.

I checked XML and Token Variables, but I’m seeing the same issue in all stock MSFS aircraft as well, so I guess it’s a global issue that affects all API’s including html.

5 Likes

I can confirm the problem. LOCAL TIME is returning ZULU TIME instead

Also, because the clock in the sim continues to run but the UI isn’t updating, the UI quickly ends up not showing the correct time even in UTC. Sim Time on the NB21 Logger simconnect app is reading the “E:LOCAL TIME” simvar from MSFS2024 in the pic below.

Confimed. This code for instance was showing a model every 15 minutes for 15 minutes on the first day of each month. In MSFS2024 it shows the model for every 1st day of the month, but for the whole day:

                	(E:LOCAL DAY OF MONTH, Number) 1 ==
		(E:ZULU TIME, minutes) 60 % flr 15 >= and
		(E:ZULU TIME, minutes) 60 % flr 30 <= and
		(E:ZULU TIME, minutes) 60 % flr 45 >= or if{ 1 } els{ 0 }

Hi everyone,

You may not have noticed but this topic has received the “bug_logged” tag - which means we are working on fixing it. :wink:

Best regards,

Eric / Asobo

3 Likes

Hi again,

The issue should be fixed with the mid-December patch.

Best regards,

Eric / Asobo

1 Like

There is also something strange happening when trying to set either the local or zulu hours / minutes using the events ZULU_HOURS_SET, ZULU_MINUTES_SET, CLOCK_HOURS_SET, CLOCK_MINUTES_SET.
Setting the hours seems to change the time in the sim (e.g. it can go from daytime to nighttime) but the (received) time gets reverted a second or so later, although the sim will stay at dark/nigh-time. If you then try and change the minutes via those events, the sim jumps back to daytime.
Just thought I’d mention this - I will test again after the mid-December patch and report properly if still present.

@ImpoliteGem5317

You may want to create another topic since this seems to be a different problem.

Best regards,

Eric / Asobo

I posted this bug after v1.1.9 release and never got an acknowledgement.

I assumed (perhaps badly) that all these time related issues were related and were all going to be addressed in the latest patch.

I also cross referenced it in the other time bug thread. Could you please confirm whether this was addressed in this most recent patch release (I haven’t updated yet or been in sim).

Thanks.

Update:
@FlyingRaccoon @EPellissier
This is still broken in Release V1.2.7.0

Getting back to the initial topic: @some1 @vpilotfs @B21 @Sasa - could you confirm whether the ZULU time issue is fixed for you in 1.2.7.0?

Best regards,

Eric / Asobo

The LOCAL TIME and ZULU TIME simvars now seem to work correctly, thanks!

However, the date related ZULU simvars (day, month, year) still show the system date and not the date set in the simulator. LOCAL date simvars seem ok.

1 Like

I looked at the LOCAL TIME and ZULU TIME simvars (not the date) - these are now remaining in sync with their respective relative offset as expected.

We have usability issues with the time displayed on the World Map becoming increasing wrong depending how long ago that value was set in the Flight Conditions menu but shouldn’t clutter this thread with that if it’d be preferred separate.

I can confirm that it still does not work in 1.2.7.0 (SimConnect). Sorry if this should be posted in another thread.

In MSFS 2020, you would use this (if using managed VB.NET which would be similar in C#).

To get the time on every interval, you would use this:

msfs_simconnect.AddToDataDefinition(StructDefinitions.Struct1, “ZULU DAY OF YEAR”, “number”, SIMCONNECT_DATATYPE.FLOAT64, 0, 14)
msfs_simconnect.AddToDataDefinition(StructDefinitions.Struct1, “ZULU TIME”, “seconds”, SIMCONNECT_DATATYPE.FLOAT64, 0, 15)
msfs_simconnect.AddToDataDefinition(StructDefinitions.Struct1, “ZULU YEAR”, “years”, SIMCONNECT_DATATYPE.FLOAT64, 0, 16)

To set the time, you would use this (which no longer works in MSFS 2024:

msfs_simconnect.MapClientEventToSimEvent(SIM_EVENTS.ZULU_YEAR_SET, “ZULU_YEAR_SET”)
msfs_simconnect.MapClientEventToSimEvent(SIM_EVENTS.ZULU_DAY_SET, “ZULU_DAY_SET”)
msfs_simconnect.MapClientEventToSimEvent(SIM_EVENTS.ZULU_HOURS_SET, “ZULU_HOURS_SET”)
msfs_simconnect.MapClientEventToSimEvent(SIM_EVENTS.ZULU_MINUTES_SET, “ZULU_MINUTES_SET”

msfs_simconnect.TransmitClientEvent(0, SIM_EVENTS.ZULU_YEAR_SET, intYears, GROUP_ID.GROUP_1, SIMCONNECT_EVENT_FLAG.GROUPID_IS_PRIORITY)
msfs_simconnect.TransmitClientEvent(0, SIM_EVENTS.ZULU_DAY_SET, intDays, GROUP_ID.GROUP_1, SIMCONNECT_EVENT_FLAG.GROUPID_IS_PRIORITY)
msfs_simconnect.TransmitClientEvent(0, SIM_EVENTS.ZULU_HOURS_SET, intHours, GROUP_ID.GROUP_1, SIMCONNECT_EVENT_FLAG.GROUPID_IS_PRIORITY)
msfs_simconnect.TransmitClientEvent(0, SIM_EVENTS.ZULU_MINUTES_SET, intMinutes, GROUP_ID.GROUP_1, SIMCONNECT_EVENT_FLAG.GROUPID_IS_PRIORITY)

When setting, year, month, and day seem to be ignored, and the time is incorrect.

Hope this of some help.

1 Like

I confirm the ZULU vars are still showing system time and not the configured sim flight time.

Damn, you’re right…
I only filed in a bug for ZULU_TIME so only this one was fixed. :frowning:

I talked to the person in charge and I have just pushed a fix for the other simvars in our development branch - I will let you know when I have an ETA.
Apologies for this.

Best regards,

Eric / Asobo

It would be easier to track this issue through a separate thread indeed. :wink:
Thanks a lot!

Best regards,

Eric / Asobo

1 Like

Hi,
i just want to make sure, it might be related… Im based in Europe. Jumping into an aircraft, e.g. in Canada with Live Time enabled results in a dark enviorement (since its prior sunrise right now) but the aircraft lights etc behave like its daytime so they are barely visible; its looking like night, but the lights dont work as “they think” / behave its daytime (that is another problem to be fixed) but this is about the messed up times.

CYQT 06:32 Local, 11:32 GMT
Lights are fully set on


Quick feedback from my side: This code mentioned above works now as intended:

Any updates on this? The ZULU_…_SET events appear to either be broken entirely, or setting one resets the other (in the case of hours and minutes, for example).

I am resorting to having to write a Python daemon to update the simulator time to account for sim rate changes, since that worked fine in MSFS2020 (a 2x sim rate would also update the in-sim date time twice as fast / 2 seconds for every 1 real life second, for example) but is broken in MSFS2024. But, I can’t even do it through a script if the simulator refuses to have its datetime overridden.

This gets even weirder, because ZULU_MINUTES_SET doesn’t appear to have an upper bound at 59, so you can give it positive offsets that exceed that, which sets the time to the top of the current live hour, plus whatever minute offset.

So if the IRL zulu time is 0705z, and you do ZULU_MINUTES_SET(123), you get 0903, because that’s 123 minutes off of 0700z.

This is all just broken. ZULU_HOURS_SET sets the hour, but resets the year, day of year, and minutes to match real life; while ZULU_MINUTES_SET resets the year, day of year, and hour to the match real life, and then sets a minute offset off it.

So the only way to actually set the datetime, is to calculate it as an offset off of the top of the current real life hour. ZULU_MINUTES_SET accepts things like 1440 to set the datetime to a whole 24 hours off of the top of the real life datetime’s hour, 2880 for 2 days (48 hours), and so on.

But of course, you better only need to set a positive offset…

Seeing as it takes a u16, passing -1 is passing 0xFFFF, which is 65,535, which, you guessed it, sets the date forward 45 days and some change.

CLOCK_HOURS_SET and CLOCK_MINUTES_SET exhibit the same behavior where they reset each other. Sigh.

And of course there’s no way to set the seconds, nor do any of the ZULU_…_SET events reset the seconds to 0, nor does CLOCK_SECONDS_ZERO actually do anything.