The time on the aircraft is shown in local time. I read that adb-s messages do not have a timestamp segment (true or false). What is the “local time” data source for the plane shown on the software interface? Is it reliable since it should in some but not all cases change +/-1 hour when passing over country boundaries?
Kind regards
What time shown where?
Correct.
What software interface?
2 Likes
By interface i mean software tracking programs such as flightaware or any other (SkyGlass, adbs, flighttracker24 etc). My question is still valid, what is the source of the aircraft local time if not GPS? How does local time of a plane get attached to the plane since it May/May not change +/- 1 hour when crossing country Borders & in summer/winter time ofsets.
For the FlightAware website, we capture everything in UTC (well, technically, seconds-since-the-epoch) and do any requested conversion to local timezones at the point of display. We don’t use the instantaneous aircraft position to decide on the timezone – it’s generally either the timezone you’ve configured on your account, or the origin or destination airport timezone. e.g. I have my account configured to show everything directly in UTC. (See also the note on the tracklog page which explicitly tells you that it’s all in one timezone to reduce confusion)
For AeroAPI, Firehose et al, it’s all in UTC.
For other software you’d have to ask the provider of the software.
1 Like
Ok.UTC time i ASSUME comes from GPS coordinates but calculated in your software or? Eg. How is Madrid local time utc+2 if u use GPS cordinates? The local time displayed on the plane in your software must have a source-perhaps it is derived/calculated from the map that u use in the software. Still not Clear.
I’m not sure what you’re asking. Each position that we record has a timestamp associated with it.
For ADS-B positions, that’s just the time that the position message was received. In turn, that time comes from the system clocks of the FlightAware servers and (sometimes) the edge receivers, which are synchronized by NTP.
For other position types the timestamp might come from further upstream, e.g. recorded by a radar system maintained by an ANSP at the time the position is computed, and that timestamp then makes its way down to us as metadata associated with the position (even if we only receive it some time later)
GPS time might ultimately be one of the time sources used for synchronizing those system clocks, but it’s not directly used.
Local time generally doesn’t come into it at all when recording the data, none of these systems really care about what the local wallclock time is, they care more about unambiguously identifying a point in time.
For display, as I said earlier, the timezone used for display on the website is either the timezone you’ve configured on your account, or it’s the timezone of the origin or destination airport. We have an internal database of airport data that includes timezone info.
1 Like
We previously agreed that neither adb-s messages nor GPS data contain a time segment. Ok. Pls be patient 
how do you in flightaware show the plane local time (UTP+2 in summer) in Zaragoza (Spain) as let’s say 15:25 when in Grenwich the local time is 13:25. They are both on the same meridian. GPS coordinates would give incorrect time. mmm is the position of the plane being communicated to flightaware by thousands of “stations” around the Globe that give the local time? If this is getting too confusing please say so-I may try and find the answer elsewhere-with all due respect.
Well, I mean, GPS most definitely includes time, that’s fundamental to how it works, but apart from that …
Let’s say that at 2023-05-30 13:25:00 UTC, the aircraft transmits a position message. A very small amount of time later, one of our receivers, say, somewhere in Spain (but it doesn’t matter where!) hears that message and the message is forwarded to our servers.
The server’s clock is synchronized to UTC via NTP. It records the position together with the time that it was received - 2023-05-30 13:25:00 UTC.
Later, you look on the website for that flight. Your account is configured to “Display flights in flight’s time zone”. The flight departed from LEZG. So the website does essentially this:
- The position time is 2023-05-30 13:25:00 UTC
- The flight origin airport is LEZG
- The timezone for LEZG is (using the tzdata timezone name) Europe/Madrid
- Therefore, I should convert 2023-05-30 13:25:00 to local time using the Europe/Madrid timezone rules
- Therefore, the local time to display is 2023-05-30 15:25:00 (CEST)
No coordinates involved; the only geographic thing here is that we have a database that says “the timezone for LEZG is Europe/Madrid”.
(I’m oversimplifying a bit here, because there are many possible places you could see a local time, but the general rule is the same - we decide on a timezone to use based on the airports involved & your account settings, and then convert UTC times to local times according to that timezone)
1 Like
If the plane flying over Spain was going to Tokyo it would not show the local time of Tokyo. I understand from your last message that the message recieved by flightaware contains the date of the local “reporter” who is communicating/sharing the data of the plane/s therefore no calculation or Correction is necessary at all. It is simply a data share.
Many thanks & regards.
Not exactly – it’s more that everything is reporting in UTC, not in local time.
Don’t see a non-stop flight from LEMD - RJAA, but here’s one from Paris:
and we actually do show both timezones:
1 Like
The most simplistic answer is.
Everything uses UTC/epoch.
Anything else is a temporary calculator shift to suit YOUR chosen settings.
Just like how regular schedule flights shift by 1hr locally when DST changes.
Does the plane leave where it come from at a different point in the daily solar cycle?. No. The UTC time remained the same.
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.