|
Post by dever23b on Oct 15, 2015 0:56:42 GMT -5
Hello again: This has been suggested before, likely more than once, but I do want to reference this thread from this forum. Can we please create flight dispatches in Zulu time? It appears, from reading logs, that FS Captain is already doing a lot of work in Zulu time anyway; it just doesn't allow us to use it.
|
|
|
Post by cbruce on Nov 2, 2015 12:51:26 GMT -5
I support this suggestion 100%. Here is a scenario why:
I live in Brazil but I fly all over the world. Today I flew EHAM-EGLL, I looked up a real flight for today and found one leaving EHAM at 1305z (1405 local Amsterdam time). So I set up the charter flight with no start time and set the sim (P3D 2.5) to 1/2 before with the GMT time box checked, so this being 1235z.
But the FCDU shows 0935z !! I think it is taking the zulu time I put in the sim and deducting the 3 hour time difference in Brazil (Brasilia time) which is odd given this is meant to be zulu time. Worse still, the time difference is no longer 3 hours but 2 because of the end Oct time change.
In summary, if I set my sim to GMT time with the box checked, FSCapt is still interpreting this as my local time in Brazil, and this local time is also wrong!!
This confusion means I cannot set up any schedule flights because I have a big risk of the wrong time coming out and sitting in the cockpit for over an hour for my passengers to arrive!! This happened recently when I did a scheduled flight in Brazil starting at 1500 local time which is 1700z, but FSCapt calculated zulu as 1800z so when I got in my cockpit at 1630z I had to wait 1,5 hours!
So yes please, nothing but Zulu time everywhere would be the answer
Best Charles
|
|
|
Post by Travis on Nov 2, 2015 15:18:36 GMT -5
This will be an option in the future.
In the meantime, please know that FSCaptain only gets time data from the sim itself, we do not perform any time zone difference calculations. There are two sets of environmental variables - Zulu (time, day of year, etc.) and Local.
The big trick (in my limited tests) is determining how to convert "local time" schedules (like the TT-generated schedules) into "Zulu everywhere" schedules.
I've noted where I should test the P3D time GMT entry that you referenced. I've been puzzled over that option with P3D myself, so I should take some time and get my hands really dirty with it.
Regards,
|
|
|
Post by dever23b on Nov 7, 2015 1:01:33 GMT -5
This will be an option in the future. In the meantime, please know that FSCaptain only gets time data from the sim itself, we do not perform any time zone difference calculations. There are two sets of environmental variables - Zulu (time, day of year, etc.) and Local. The big trick (in my limited tests) is determining how to convert "local time" schedules (like the TT-generated schedules) into "Zulu everywhere" schedules. I've noted where I should test the P3D time GMT entry that you referenced. I've been puzzled over that option with P3D myself, so I should take some time and get my hands really dirty with it. Regards, Just curious: could you elaborate on your dilemma with converting local times to Z? I just finished a project where I had to deal with a potentially similar dilemma.
|
|
|
Post by dever23b on Nov 7, 2015 1:07:03 GMT -5
Hello again: Travis's comment in this thread reminded me to ask for some help regarding times. I'm running into an issue where, and I suspect this has to do with FSX's old DST settings no longer matching real world updates, I'm having trouble meeting departure times on the flights I dispatch with FS Captain. Throughout all of my mumbo-jumbo involved with dispatching my flights, I end up with accurate local times that I feed into FS Captain. Then I get all ready to start my pre-flight when I finally remember that FSX's DST settings are wrong, so FS Captain won't let me board for another hour. So, I end up having to delete my flight in FS Captain and re-dispatch it with wrong times so that I can fly it at my actual scheduled time. Two questions: 1) Is there a way you know if that I can fix this in FS on my own (ie: without needing to buy FS RealTime, which I haven't decided on yet) 2) You suggested that Zulu times may be available to us in the near future -- will this solve the problem, do you think?
|
|
|
Post by peter on Nov 7, 2015 5:25:08 GMT -5
Hi Dever23b,
as far as I know, the big problem is that time zones are faulty in FSX. Some users will want to have the time correct as in reality, which means local sim time must be wrong. Other may prefer it the other way round. For people in some time zones things might work perfectly while others (like me) have to live with FSX getting it wrong all the time. Daylight savings is not implemented consistently, so that doubles the issues. And some people use FSRealTime, which fixes time zones but not daylight savings, I believe.
So local time in FSX is a big mess, but in real life scheduled flights are always scheduled in local time. Dutch had to make a decision and went with local time. However, Zulu time has its advantages and I could imagine that FSCaptain could simply offer both times and not care about whether they are correctly synchronized or not. Another option could be to leave synchronization to the user - for instance, by manually adding time offsets to scheduled flights.
If your project only involves time conversion for real life time zones, that's much easier. There are time zone converters available for free that you can embed in a C++ program, for instance.
Cheers, Peter
|
|
|
Post by peter on Nov 7, 2015 5:39:21 GMT -5
Hi Dever23b,
sorry, I replied to your other post without having seen this one.
1) I tried to work on an actual fix, but failed. FS RealTime helps somewhat, but if I remember correctly there are issues with daylight savings. It's been a while that I used it, though. I didn't install it when I migrated to P3D.
A work-around to get scheduled flights offered is to set the local time in FSX to a time that fits to your departure time. For instance, if your flight is scheduled for 10:30, set local time to 10:10 or so when you start FSX. Of course that means that your sim time is not synchronized to real time and the location of the sun in the sky may be wrong. The latter point is why I would prefer Zulu time. I tend to fly in my evenings and never like it when it is already dark in the sim while outside it is still bright.
2) Zulu time would resolve many problems, but create others. If flights were scheduled in Zulu time then you just would need to keep FSX synched with real time and could be sure that a scheduled flight will be offered when you are at the gate on time. On the other hand, if you want your flights to depart at a specific local time (e.g., because you want to emulate the flights of a real airline), then using Zulu time could get that wrong.
Cheers, Peter
|
|
|
Post by dever23b on Nov 7, 2015 12:51:20 GMT -5
Peter:
Thanks for the reply. Why would zulu time make flying at a custom time not possible? I guess I don't understand why simply using a "real" time as opposed to a local-offset would have to be strictly correlated to flying "live." More specifically, why would a change to use Zulu time force people to fly in real time?
|
|
|
Post by dever23b on Nov 7, 2015 13:04:03 GMT -5
Peter:
Now it's my turn to apologize for replying to another thread without reading this one first! Sorry about that.
I thought I was being helpful by separating the threads into "support request" versus "new idea discussion" but perhaps that idea was flawed.
Here's where I'm getting confused. If you were to evaluate the current Zulu time that FS is reporting, and then apply a timezone offset (including DST if applicable) for display purposes... why would it matter what the FS local time is? It seems like, if you dealt in Zulu, you could sync with the FS Zulu time and never have to worry about timezones or DST. When a need arises to display local time (such as for a schedule), you could simply apply an offset to the "real" zulu time (real = FS time without offsets), and display your computed local time -- only for display purposes. However, if you did all of your calculations based on the real time, then any inconsistencies in timezone/DST offsets would be moot points and thusly ignored for the purposes of calculating timely flights. What am I missing?
However, in the event that my theory is flawed, I'd recommend offering a flag in the configuration settings: allow the user to select whether they wish for FS Captain to sync to FS Local time or FS Zulu time. That would allow people to have their cake and eat it too: if their local offsets are incorrect and they wish to fly with real local times, they can; if they would prefer to use Zulu time, they also can.
All this being said, I want to make sure that my request doesn't get squashed here... while I am certainly interested in a global switch(/ability) to sync to FS Zulu times, the spirit of my original request was to allow us to specify flight times in Zulu (as they are dispatched and filed in real life) when we are creating our own flights in FS Captain. I imagine this request would be somewhat more simple than a global change in how FS Captain syncs time with FS. I like that, don't get me wrong! I just want to make sure I clarified that my original request was specifically in regard to creating flights manually on the dispatch page.
|
|
|
Post by Travis on Nov 7, 2015 14:27:26 GMT -5
I live in Brazil but I fly all over the world. Today I flew EHAM-EGLL, I looked up a real flight for today and found one leaving EHAM at 1305z (1405 local Amsterdam time). So I set up the charter flight with no start time and set the sim (P3D 2.5) to 1/2 before with the GMT time box checked, so this being 1235z. But the FCDU shows 0935z !! I think it is taking the zulu time I put in the sim and deducting the 3 hour time difference in Brazil (Brasilia time) which is odd given this is meant to be zulu time. Worse still, the time difference is no longer 3 hours but 2 because of the end Oct time change. In summary, if I set my sim to GMT time with the box checked, FSCapt is still interpreting this as my local time in Brazil, and this local time is also wrong!! Just now, I did this in P3D 2.5 - I chose EHAM and set the GMT time to 1305, which should be early afternoon there. The simulator came up in total darkness - 0505(AM) GMT if I recall correctly - 0505 would be near to what my local time (California) should have been. I then went to the Time dialog and set that to 1305 GMT, and soon enough the time was set properly. I lost beaucoup VAS in doing so, but it's clear to me that for P3D 2 at least, the time at the opening screen is not being set as we would expect it to be. (I then tried the same experiment in FSX and that functioned as I expected, a nice sunny afternoon with rather gusty winds.)
|
|
|
Post by Travis on Nov 7, 2015 14:48:01 GMT -5
Okay, I've merged threads together here. Our simulators use their own, flawed time zone database. And it would be possible that your TZ database is different than mine, or Peter's. So a proper converter would have to run on each Captain's PC, pull the time zone offset from the BGL (or set of BGLs, I'm not certain) and apply that to the current schedules. I'm not up to speed on how the BGL information is encoded - I did find a tool to decompile scenery BGLs into XML years ago, and from that I could read data. But it didn't seem to work with the time zone data. The faulty DST settings aside, I still wonder what the source of the FSX problems are. I just proved to myself that P3D2's time settings are funky, but when I use FSX and I want to fly from somewhere in the other side of the world... let's say from YPKU at 8am (YPKU time), I start at the Free Flight screen (with the default Friday Harbor trike flight), select my aircraft, select my airport, and then set the local time. Presto. It's currently 0000z and I can start my flight that's scheduled to depart at 0820 local time.
(Fun fact, the FCDU does require you to open the door to the trike before boarding your passenger. )
I guess I should break down and purchase FS RealTime one day. I'd hope it would be P3D3 compatible since I want to migrate to there.
Could you give me a detailed step-by-step description of how you schedule and start a flight that's doomed to be off-time? I'll mimic that here and see what I come up with.
|
|
|
Post by Travis on Nov 7, 2015 14:56:48 GMT -5
Here's the times from the Dispatch Release that all look correct - I went out at 0003Z for an 0820 local departure - I included the fuel bits for those who want to see the funny....
FLIGHT 8146 YPKU (KNX) -- YSSY (SYD) -- ALT YWOL (WOL) 08-NOV-15 08:20L ARRIVE 23:59L
AIRCRAFT ZZ9ZA OUT: 08-NOV-15 00:03Z OFF: _______ TYPE trike ON: _______ IN: _______
CREW INFORMATION: DISP: J H KENT / ____________________________ (SIGNED) PIC : RUFUS T. FIREFLY / ____________________________ (SIGNED)
FUEL CALCULATION WEIGHT/FUEL BREAKDOWN MIN 0LB ZFW 720LB TAXI 25LB 25MIN T/O FOB 33LB (MAX: 45LB) YSSY 1167LB 1671MIN PLANNED TOW 753LB YWOL 0LB 0MIN ENROUTE BURN 1167LB RSV 45LB 45MIN PLANNED LDW 793LB (MAX: 983LB) HOLD 15LB 15MIN ARRIVAL FOB 60LB (ESTD) ************************* TOTAL 1252LB 1756MIN
** This flight will require at least 27 refueling stops. ** It is the PIC's duty to manage fuel accordingly, ** and maintain the minimum flight amount of 60LB ** at all times unless directed otherwise by authorities.
|
|
|
Post by DirkDP on Nov 7, 2015 15:56:12 GMT -5
Hi,
Here's how I get around the lima/zulu stuff. In my FS9 I have the updated TZ bgls from Dennis Thompson (at AVSim), big improvement. I set up my (VA) flight using zulu time, and check in FS9 dep and arr local time for those zulu times. I then create the flight in the Admin with the local times FS9 comes up with.
DDP.
|
|
|
Post by peter on Nov 7, 2015 17:40:28 GMT -5
Just now, I did this in P3D 2.5 - I chose EHAM and set the GMT time to 1305, which should be early afternoon there. The simulator came up in total darkness - 0505(AM) GMT if I recall correctly Yep, that nicely illustrates all the pitfalls of dealing with time in FSX etc. I happen to agree with Dever23b: Zulu would be nice as an option. I have the time issue in P3D (2.5 and 3.0) as well. However, it's just a glitch in the welcome screen. If you change time (Zulu or local) while in the plane it works fine. Sigh... Peter
|
|
|
Post by dever23b on Nov 7, 2015 23:19:44 GMT -5
Okay, I've merged threads together here. Could you give me a detailed step-by-step description of how you schedule and start a flight that's doomed to be off-time? I'll mimic that here and see what I come up with.
Travis: I shall begin with a disclaimer: I haven't checked my theory against fact yet. I'm assuming that the changes to DST a few years back (in the US, at least -- reference) are causing me to end up in this limbo, where FSX hasn't observed the DST change while the real world has. If my theory is correct, then my problem will go away in a few weeks. Notwithstanding, here's what happened yesterday when I attempted a flight. My flight was from KBOI-KDEN. To save you time, KBOI is UTC-7 for standard time, and UTC-6 during DST ( reference). I prepared my dispatch on SimBrief ( KBOIKDEN_PDF_1446825332.pdf (290.45 KB)), with a proposed departure of 1630Z (which would be 0930L, which SimBrief correctly calculated). I then created my dispatch in FS Captain ( KBOI-KDEN_FSC_2015-11-06.pdf (36.57 KB)) using the local times from SimBrief. I took a little longer than I'd anticipated with my dispatching, so I cheated (I know, I was bad...) and added 20 minutes to my proposed time in FS Captain, resulting in a proposed 0950L. I then loaded up FSX and set the Date & Time to the real Zulu time, which was 1630Z. FSX had not observed the time change yet, though, so FSX calculated the local time to be 0830L instead of 0930L. Accordingly, when I powered on the FCDU to accept my flight, despite the FCDU acknowledging that the Zulu time was correct, it told me I needed to wait 40 minutes to board my plane. What I've done in the past is simply shut down FCDU, reload Administrator, erase my flight, and completely recreate the flight (again...), subtracting an hour from my proposed time. I hope this makes sense/leads you in the right direction. Respectfully,
|
|