I have noticed a minor but somewhat annoying issue with P3D v4.5 when I am at the flight loading screen and I select the season and time of day. What happens is that unless the flight is in the same time zone as my own default flight then it bases the image next to the time selection options (which reflects the season and time of day) based on that my own time zone would appear like rather than where the flight is going to actually take place.

So for example, my default flight time zone is at my local airport here in Australia (YBLA) and we are of course dead in the middle of Winter and it is dark by 6.00 PM. But I then choose a US based airport for example to fly out of and set the time to Summer, 6.00 PM as an example. Obviously Summer at 6.00 PM is still light, but the image shows what it would be like in Winter here in Australia, not Summer in the US.

As I say it is only an annoyance since the flight still loads with the correct local time and season but it seems like I must have some sort of setting wrong for the accompanying image to reflect incorrectly. And yes, if I am after a very particular time of day I then use the excellent time of day preview function to get it exactly as I need it but the image when selecting the flight normally saves me that extra step as it is accurate - but only for my own time zone.

So not a biggie obviously but since I am at the stage now where I am fine tuning my new P3D setup on the new computer, I thought I had better check just incase I have missed something somewhere.

If check the box for UTC time in thee P3D Time and Season inputs and always set the time in UTC, then that should solve your problem. Simbrief plans flights in UTC as well so that's the way I handle that issue.

Is "Use system time," checked?

I think the date/stime screen can be buggy.  I always uncheck/check again the UTC time, and input the date/time in UTC. 

Same here on v5.4, when I hit "Reset to system time" it always goes same local time, even with the "UTC time" checked.

• Thanks for all the replies. In my case Zatoichi had it correct. I changed the SYSTIME parameter in the cfg file from 1 to 0 (can be done via user interface or manual edit) and it all now works perfectly. I'm not sure a value of 1 was intended to cause the behaviour I mentioned - probably a bug I'd say - but I am happy to set it to 0 to resolve the issue.