Jump to content
The simFlight Network Forums
Sign in to follow this  
flying-w

Problems with date & time in P3D V3.2

Recommended Posts

Hi Everyone

I think I have tracked down where the problems people are having with STB are coming from since upgrading to Prepar3D V3.2.  STB needs detailed information about the current time in the simulator, and it gets updated with this information every 15 seconds.  However the format of this information seems to have changed in Prepar3D V3.2 compared with V3.1, V2 and FSX, and there also seems to be a bug with timezones.  Here's an example:

 

1) In Prepar3D V3.1, set your simulator to airport EGCC on Sunday 21/6/2015 at 00:05:31 (BST/Local time).  In simulator "zulu" time, this is Saturday 20/6/2015 23:05:31 GMT (Zulu) due to the British Summer time being 1 hour ahead of GMT.  If I connect STB to the simulator, here's the information I get back about time:

FSPeriodicSignal nt.absoluteTime: 3440896187
FSPeriodicSignal nt.localDaySeconds: 331
FSPeriodicSignal nt.localMonth: 6
FSPeriodicSignal nt.localMonthDay: 21
FSPeriodicSignal nt.localSimDay: 0
FSPeriodicSignal nt.localYear: 2015
FSPeriodicSignal nt.timeZoneOffset: -60
FSPeriodicSignal nt.zuluDaySeconds: 83131

FSPeriodicSignal nt.zuluSimDay: 6

 

The important ones is are:

i) "localSimDay", this is the local simulator day of the week number.  Day "0" is the start of the week which in all simulators up to and including P3D V3.1 is "Sunday".

ii) "zuluSimDay" is the zulu simulator day of the week number.  Day "6" is Saturday.

 

Both of these are fundamental to all time calculations in STB, and STB is designed to expect all of the above and works correctly.

 

2) Repeat the above in Prepar3D V3.2.  This time we get:

20/03/2016 08:34:42.536: FSPeriodicSignal nt.absoluteTime: 3440896187
20/03/2016 08:34:42.536: FSPeriodicSignal nt.localDaySeconds: 331
20/03/2016 08:34:42.536: FSPeriodicSignal nt.localMonth: 6
20/03/2016 08:34:42.536: FSPeriodicSignal nt.localMonthDay: 21
20/03/2016 08:34:42.536: FSPeriodicSignal nt.localSimDay: 1
20/03/2016 08:34:42.536: FSPeriodicSignal nt.localYear: 2015
20/03/2016 08:34:42.536: FSPeriodicSignal nt.timeZoneOffset: -60
20/03/2016 08:34:42.536: FSPeriodicSignal nt.zuluDaySeconds: 83131
20/03/2016 08:34:42.536: FSPeriodicSignal nt.zuluSimDay: 1

 

Again the important ones is are:

i) "localSimDay".  However instead of Day "0" for the start of the week we now get Day "1".  Further more the last day of the week is now Day "7" for a Saturday, where in previous versions of the simulator it was Day 6.

ii) "zuluSimDay" seems to have a timezone bug.  We are getting Day "1", i.e. Sunday, but Zulu time should be on Saturday as it is 1 hour behind so we should be getting day "7" in the "new" day numbering convention.

 

So what does all this mean in STB:

- When the simulator has local day set to Saturday, day "7" in this brave new world, you will see exceptions in STB like those already reported on the forum here.  We cannot translate day 7 into a day name as we never expected it.  This has a knock on effect everywhere else.

- The calculation of departure and arrival times for predicted flights (those that do not not have an AI aircraft to operate them yet) are all a day out.

- The "current simulator date/time" as displayed on STB in the top left corner is a day out.

 

post-12182-0-69008600-1458465840_thumb.p

 

I may be able to fix this on my side but I'd prefer not to as I need Prepar3D to deliver me reliable and predictable date and time information.  That said while I can report this to LM but I don't know if it will garner there interest.  In the meantime, if your STB experience is important to you in STB P3D V3.2, please avoid flying with the simulator set to a Saturday and avoid timezones where the current time occurs on a different day to the zulu time.

 

Finally a number of people have suspected the influence of other products in this problem.  I can't find evidence for that in the light of the above investigation, but if you are seeing something different I'd be glad to investigate further.

 

 

Share this post


Link to post
Share on other sites

Hello Simon ,

Indeed, yesterday, Saturday , STB can not be used again with an error message, and oh miracle this morning normal operation.

Looking at my last post , I had actually made the update FSIUPC but Sunday morning, which could to make me believe that the problem came from .

Thank you very much for your analysis is objective and thank you for this wonderful program I always used ( except Saturdays now lol)

Share this post


Link to post
Share on other sites

No error messages today, Sunday either. That's with ASN 5921, FSUIPC 4.949i. Spotted a Etihad 787-900 landing at KIAD-Dulles. Nice.

 

Do you want us to bring this up on LMs forum (their Gremlins) or can you get to someone there more directly?

Edited by Psybear

Share this post


Link to post
Share on other sites

No error messages today, Sunday either. That's with ASN 5929, FSUIPC 4.949i. Spotted a Etihad 787-900 landing at KIAD-Dulles. Nice.

 

Do you want us to bring this up on LMs forum (their Gremlins) or can you get to someone there more directly?

 

I'm afraid I don't have a hotline, I can just append to the forum like everyone else and hope someone notices.  Let me present my evidence first of all and see if it gets us anywhere.  I'm travelling again next week, so it might be a few days before I can get it out there.

Simon

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

×