MSFS2024 and setting the time

[NeoGeo78]

Hi Paul,

I hope all is well. I seem to be having an issue with setting HH:MM in MSFS2024 (works fine in 2020 etc). In particular:

            // Sets the local time 
            DateTime newDateTime = new DateTime(2024, 7, 1, 4, 05, 0);
            FSUIPCConnection.UTCDateTime = newDateTime;

It seems I can set the Year, Month, and Day, but for some reason, the Hours and Minutes always default to the actual real-world time, preventing me from setting a custom time. Perhaps Microsoft has changed how this feature works in 2024, but I was wondering if you are aware of this issue or know of a possible workaround?

The same issue occurs when using FSUIPCConnection.LocalDateTime.

I’ve tested this with your DLL versions 3.3.8 and the latest 3.3.13, alongside the latest FSUIPC version and the new BETA version that John released this week but still no joy.

I hope the last few week shavent been too stressful for you!

Thanks

[Paul Henty]

I think this is a question for @John Dowson.

My DLL just writes the hours to offset 0x023B and minutes to 0x023C regardless of what sim you're connected to.

Paul 

[John Dowson]

30 minutes ago, Paul Henty said:

I think this is a question for @John Dowson.

My DLL just writes the hours to offset 0x023B and minutes to 0x023C regardless of what sim you're connected to.

I am not sure why this would be - I will take a look sometime next week.

[NeoGeo78]

One other obeservaton is I see it very briefly setting the time to the one I specified but then the sim changes the hours and mins to the local real time. Anyhow, thanks for the quick replies - have a good weekend!

[Dabull]

I am experiencing this too. I can set the localMinute but not the hour. It seems to default to the local hour.

[John Dowson]

On 12/2/2024 at 8:15 PM, Dabull said:

I can set the localMinute but not the hour.

Really? That is interesting - how are you setting the local minutes?
I have checked offsets 0x023B and 0x023C and writing to those in MSFS2024 doesn't change the hours/minutes, as reported here.
I have also tried switching to use the  CLOCK_HOURS_SET and CLOCK_MINUTES_SET events (they currently use ZULU_HOURS_SET and ZULU_MINUTES_SET) and they don't work either.
Checked in MSFS2020 and they are still working there.

There is not much I can do about this at the moment except report to Asobo. I will update the Offset Status document for FSUIPC7 to mark these as read-only for MSFS2024 for the time being.

John

[John Dowson]

Also offsets 0x0238 and 0x0239 (which use the CLOCK_HOURS_SET and CLOCK_MINUTES_SET events) also have issues in  MSFS2024 whereas they work ok in MSFS2020. I can set the hour, and it seems to work. However, when I then set the minutes, the hours go back to its original value, but the minutes are updated.
In fact, setting one seems to reset the other (back to zulu values), and the zulu times are also not updated.

 

Edited December 5 by John Dowson
Further info added

[John Dowson]

I turned off on-line services (weather and AI traffic) and after doing this I can set the zulu hours and minutes in offsets 0x023B and 0x023C. Setting the hours seems to work (i.e. it goes from day to night in the sim) but the offset gets reset but the sim stays in night for some reason, And, as with offsets 0x0238 and 0x0239, setting the hours resets the minutes, and setting the minutes resets the hours. Very strange...!

This works as expected in MSFS2020 (where setting zulu time also updates local time and vica versa), so its definitely an issue with MSFS2024. I will report to Asobo.

[NeoGeo78]

Hi John - thanks for the update and appreciate you spending the time looking at this.

[NeoGeo78]

Also, interestingly, I saw that the second most community reported bug is in relation to Live Weather not seperating from the Date. Maybe related?
 

 

[John Dowson]

1 minute ago, NeoGeo78 said:

I saw that the second most community reported bug is in relation to Live Weather not seperating from the Date. Maybe related?

Maybe...
There are certainly issues to consider with live weather when adjusting the sim time, and I am not sure how MSFS handles this. There are also issues with live traffic - I am also not sure how this is handled if you are changing the current time... Historical weather is certainly available, but I don't think this is available for traffc! Presumably live traffic is turned off if you change the time, or maybe you can't change the time if using live traffic (and maybe weather)...

 

[Dabull]

10 hours ago, John Dowson said:

Really? That is interesting - how are you setting the local minutes?
I have checked offsets 0x023B and 0x023C and writing to those in MSFS2024 doesn't change the hours/minutes, as reported here.
I have also tried switching to use the  CLOCK_HOURS_SET and CLOCK_MINUTES_SET events (they currently use ZULU_HOURS_SET and ZULU_MINUTES_SET) and they don't work either.
Checked in MSFS2020 and they are still working there.

There is not much I can do about this at the moment except report to Asobo. I will update the Offset Status document for FSUIPC7 to mark these as read-only for MSFS2024 for the time being.

John

I am using offsets 0x0238 and 0x0239 respectively for hour and minutes. It worked fine in FS2020. But for FS2024 only the minute updates properly. The first time you write to the hour it sets it to the current real local time.

[NeoGeo78]

Just wanted to share another snippet I came across which hopefully looks promising:

https://devsupport.flightsimulator.com/t/time-related-simvars-are-mixed-up/11270/4

As mentioned in the link above it sounds like (fingers crossed) this may get addressed in the next patch (this week).

[John Dowson]

45 minutes ago, NeoGeo78 said:

Just wanted to share another snippet I came across which hopefully looks promising:

https://devsupport.flightsimulator.com/t/time-related-simvars-are-mixed-up/11270/4

As mentioned in the link above it sounds like (fingers crossed) this may get addressed in the next patch (this week).

Thats interesting, thanks. I was going to report this week but I will now wait for the update. I will just add a comment to that for the time being.

Cheers,

John