Database reading UTC times or local times

[Copper]

First, sorry if this topic has been raised / been highlighted and solved before but did not find any info about it:
If I´m not mistaken, earlier version read the user edited database that we create and upload, as LOCAL times for departures and arrivals.

The latest version here , reads it as UTC. Is that correctly understood? Or is something else causing our flights come up with UTC after our local departure times?


If yes, is it possible to tweak or select local times instead of UTC?

After update at our VA, all departures and arrivals, local times,  are now  shown as UTC after the time stamp.

Thus, the whole database will be wrong for our pilots.
As this VA covers several parts of the world and also several timezones, that is a huge issue.

Any suggestions how to fix this?

Rgds

Harald Lysoee
Malaysia VA
 

[ProAvia]

In the database, dpt_time and arr_time fields are varchar fields. 

The created_at, updated_at, deleted_at fields are timestamps.

 

I help manage a VA who has all their dpt_time and arr_time set in the DB as local to the dpt/arr airport. 

Those local times do not get changed to UTC anywhere or by anything.

That VA has been updated numerous times and is currently on the latest release version. Never once have those two fields changeed.

 

Timestamp will usually be in UTC or local time of the actual server location, depending on settings.

Varchar stores a short to medium string of characters.

 

Personally, I think having dpt/arr in local time (especially across multiple timezones only makes it more confusing for users. Doing everything in one time 'zone' (UTC) is much simpler.

In the real world, if you were to ask ATC for a time check you would receive the time in UTC.

[DisposableHero]

As everything else in aviation, all departure - arrival times should be in UTC too. @ProAvia is right, the flights table only stores those values as text, not datetime values (timestamps etc.), thus you can use them as you wish.

 

Considering that people use them as UTC times and prepare their schedules in UTC format, some addon themes provide UTC to Local conversions for those values. What those addons do is basically convert those "texts" to "time values" (by default they are in UTC as expected) then convert the utc to local time of the airport.

 

You can check the example below for that conversion.

 

https://github.com/FatihKoz/DisposableTheme/blob/main/resources/views/layouts/Disposable_v3/flights/table.blade.php#L42-L43

 

Good luck

[DisposableHero]

Also, if you like to store those times as local values, conversion to UTC would still be possible. 

 

Like displaying the local times directly from the flight (as you entered them), then converting the value to UTC as additional display (opposite of the example above)

[LesJar]

On 3/13/2025 at 3:17 PM, DisposableHero said:

As everything else in aviation, all departure - arrival times should be in UTC too. @ProAvia is right, the flights table only stores those values as text, not datetime values (timestamps etc.), thus you can use them as you wish.

 

Considering that people use them as UTC times and prepare their schedules in UTC format, some addon themes provide UTC to Local conversions for those values. What those addons do is basically convert those "texts" to "time values" (by default they are in UTC as expected) then convert the utc to local time of the airport.

 

You can check the example below for that conversion.

 

https://github.com/FatihKoz/DisposableTheme/blob/main/resources/views/layouts/Disposable_v3/flights/table.blade.php#L42-L43

 

Good luck

 

The conversion routine I believe uses the Timezone of the Airport obviously to work out the offset to UTC to calculate the UTC value or of course to calculate the local time from the UTC value.  There is one problem perhaps in this method is that when you upload your flight schedule and the system uses VACentral to create your Airport record for that flight then some airports in the Vacentral database I have found do not have a Timezone information.

[DisposableHero]

2 hours ago, LesJar said:

 

The conversion routine I believe uses the Timezone of the Airport obviously to work out the offset to UTC to calculate the UTC value or of course to calculate the local time from the UTC value.  There is one problem perhaps in this method is that when you upload your flight schedule and the system uses VACentral to create your Airport record for that flight then some airports in the Vacentral database I have found do not have a Timezone information.

 

If you know the timezone of the airport in question then you can edit and have a correct record. Like in many other errors (like missing ICAO, wrong IATA, old name etc.) an admin can always edit the airport records via admin interface.

 

Good luck

 

BTW, conversion uses Carbon interface and yes it uses the timezone value (it has to)

[LesJar]

3 hours ago, DisposableHero said:

 

If you know the timezone of the airport in question then you can edit and have a correct record. Like in many other errors (like missing ICAO, wrong IATA, old name etc.) an admin can always edit the airport records via admin interface.

 

Good luck

 

BTW, conversion uses Carbon interface and yes it uses the timezone value (it has to)

Of course that applies once the airport is on the PHPVMS database but if you are using flight and airport data outside of PHPVMS to generate the csv files to import to PHPVMS then you need to cater for times when VACentral does not give you the correct information or has missing information.

For my purposes I use a routine that returns the Timezone from Latitude and Longitude and as such that fills in the gaps for Timezones

As I call Vacentral with a valid ICAO code then I ignore the return ICAO code from VACENTRAL but have logged it an an issue with GITHUB for VACENTRAL as some programmers might just code everything to come from the Vacentral return Data.