Flights that Cross Midnight

I'm not sure where to post this, so please re-direct me if there is a
better place.

I have a project where I have to determine the correct GMT time offset
for the arrive staton of a flight. I'm doing this for a company that
deals with airline carriers all over the world. All that I have to
work with are the depart station, depart station local time, arrive
station, arrive station local time, and the flight effective date
(which is the date the flight departs). The GMT data that I work with
is in local times per the station.

Some thoughts or questions to consider . . .

In order to get the correct GMT offset for the arrive station, I have
to know the correct date to use. This usually is not a problem,
except it can be if a flight crosses over midnight (meaning it will be
the next day at the arrival station) and the flight departed the day
before time change date.

Their current function always gets the GMT based on the effective date
of the flight. This is fine for 99% of the time. When a flight
crosses midnight and it's around time change dates, the effective date
of the flight might need to have a day added to it if the flight
crossed over midnight.

Any input or direction would be greatly appreciated.

In order to get the correct GMT offset for the arrive station, I have
to know the correct date to use.


Just let your times go past 24:00 and less than 00:00. Then do a check, and
add or subtract a day based on the result. For example, starting with 23:00,
five hours of flight, and a +2 hour offset, you end up with 30:00 on (say)
Tuesday. Then you check to see if the time is 00:00 or =24:00. Since it's
+24:00, add a day and take away 24:00. So now we have 06:00 Wednesday.

Same idea, if you start out at 03:00 Friday, a two hour flight, and a seven
hour offset (the other way) (in the Space Shuttle, presumably!), you end up
with -06:00 (six hours below zero). We check to see if this is 00:00, and if
so, ADD 24:00 and subtract a day. We h ave 18:00 Thursday.

Limit checks like this are common for all date and time conversions (in fact,
any modulo arithmetic with carry). You'll need to check to see if the date
goes past Sunday (day 7) so it can cycle "back" to Monday (day 1), see if you
passed 31 or 30 or 29 or 28 (depending on month and year) so it can cycle back
to the first of Next Month, see if we passed December, etc.

Jose

--
(for Email, make the obvious changes in my address)

Thanks for the replay.

I see you use a time of flight (we call that the elapsed time of the
flight). We calculate that by converting the depart and arrive local
times to GMT times. But, to get the correct GMT offset, you have to
know the correct date. To know the correct date, you need to know if
it is the depart date or the day after. If I can determine what date
to use to get the arrive station GMT offset, I'll have it made.


(Teacherjh) wrote in message ...

In order to get the correct GMT offset for the arrive station, I have
to know the correct date to use.


Just let your times go past 24:00 and less than 00:00. Then do a check, and
add or subtract a day based on the result. For example, starting with 23:00,
five hours of flight, and a +2 hour offset, you end up with 30:00 on (say)
Tuesday. Then you check to see if the time is 00:00 or =24:00. Since it's
+24:00, add a day and take away 24:00. So now we have 06:00 Wednesday.

Same idea, if you start out at 03:00 Friday, a two hour flight, and a seven
hour offset (the other way) (in the Space Shuttle, presumably!), you end up
with -06:00 (six hours below zero). We check to see if this is 00:00, and if
so, ADD 24:00 and subtract a day. We h ave 18:00 Thursday.

Limit checks like this are common for all date and time conversions (in fact,
any modulo arithmetic with carry). You'll need to check to see if the date
goes past Sunday (day 7) so it can cycle "back" to Monday (day 1), see if you
passed 31 or 30 or 29 or 28 (depending on month and year) so it can cycle back
to the first of Next Month, see if we passed December, etc.

Jose

"ydm9" wrote in message

If I can determine what date
to use to get the arrive station GMT offset, I'll have it made.

I would think it would make more sense to input the GMT correction, then
calculate any cross-midnight adjustment based on the flight arrival time.
The GMT offset will be a constant (+/- 1 if that locale uses DST) regardless
of your arrival time. Boston is always GMT-4 or -5, and there are only two
dates when the variable comes into play.

Boston is always GMT-4 or -5, and there are only two
dates when the variable comes into play.

Of course planes depart London on local time, not Zulu.

The U.S. & Britain don't change summer/winter times necessarily on the
same date. (I think the gap is most noticable in autumn.)

(Or perhaps that's what you were saying? But as I recall, the autumn
gap is a couple of weeks.)

all the best -- Dan Ford
email: (put Cubdriver in subject line)

The Warbird's Forum www.warbirdforum.com
The Piper Cub Forum www.pipercubforum.com
Viva Bush! blog www.vivabush.org

"Cub Driver" wrote in message
...

Boston is always GMT-4 or -5, and there are only two
dates when the variable comes into play.

Of course planes depart London on local time, not Zulu.

The U.S. & Britain don't change summer/winter times necessarily on the
same date. (I think the gap is most noticable in autumn.)

No, I meant that there are only two dates when the variable comes into play
for each station. You run the whole thing in GMT, from the computer's pov.

"Cub Driver" wrote in message
...

Boston is always GMT-4 or -5, and there are only two
dates when the variable comes into play.

Of course planes depart London on local time, not Zulu.

The U.S. & Britain don't change summer/winter times necessarily on the
same date. (I think the gap is most noticable in autumn.)

(Or perhaps that's what you were saying? But as I recall, the autumn
gap is a couple of weeks.)

Nit - UK springs ahead a week before US. They fall back on the same date.

-- David Brooks

"Cub Driver" wrote in message
...

Boston is always GMT-4 or -5, and there are only two
dates when the variable comes into play.

Of course planes depart London on local time, not Zulu.

The U.S. & Britain don't change summer/winter times necessarily on the
same date. (I think the gap is most noticable in autumn.)

Hmmm... If we are offering the OP the strategy of converting all local times
to UTC (which requires knowledge of local timezones and daylight savings
rules), there is still an ambiguity. On the day the clocks go back, the
local time of 0130 happens twice. Which occurrence do you use? Weighty
matters indeed.

-- David Brooks

We calculate that by converting the depart and arrive local
times to GMT times. But, to get the correct GMT offset, you have to
know the correct date. To know the correct date, you need to know if
it is the depart date or the day after. If I can determine what date
to use to get the arrive station GMT offset, I'll have it made.


You need to know which way you are counting, and how many hours you are
counting. I am thinking you start at Rome, and fly west to Calfornia. You
have a time difference of MINUS 8? hours. Sometimes this puts you on the same
day, and sometimes not. This has to do with what time it is in Rome. If
taking eight hours takes you "below zero" then it is the previous day.

Jose

--
(for Email, make the obvious changes in my address)

"ydm9" wrote in message
om...
[...]
Their current function always gets the GMT based on the effective date
of the flight. This is fine for 99% of the time. When a flight
crosses midnight and it's around time change dates, the effective date
of the flight might need to have a day added to it if the flight
crossed over midnight.

Any input or direction would be greatly appreciated.

I think your employers should hire a better programmer.

If you think the problem you're working on now is hard, wait until you have
to deal with a flight that crosses the International Date Line. I'm
guessing your head will explode.

Pete