The Answer by Erwin Smout is correct.
Here is example code for all three of your cases, and some discussion.
Database type TIMESTAMP WITH TIME ZONE
Your database table column should be defined as the SQL standard type TIMESTAMP WITH TIME ZONE (not WITHOUT). Or something analogous depending on your database. Support for date-time varies widely between some that are weak (SQLite) to the robust (Postgres).
Virtually all databases actually store the date-time values in UTC (if they respect time zones at all). Some retain the time zone information passed with input values while some such as Postgres discard that information after using it to adjust the value to UTC.
Think, work, and store in UTC
Your business logic and data storage should be in UTC. So there is only one actual flight time, in UTC. For the various Mexico, Singapore, and UK representations we apply various time zones for going to/from the UTC value.
Server Irrelevant
The location of the server in central US should be irrelevant. First, servers should almost always be set to UTC (or Iceland) for their time zone. Secondly, you should never depend on that setting, as it is an externality outside your control and is too terribly easy to be changed -- even during runtime! Instead, always specify your desired/expected time zone as arguments in your code.
java.time
Always use java.time classes, never the java.util.Date/.Calendar/java.text.SimpleDateFormat classes.
java.sql
Retrieve the flight time from the database as a java.sql.Timestamp which is in UTC by definition.
java.sql.Timestamp ts = myResultSet.getTimestamp( … );
As part of the old troublesome date-time classes, minimize your use of the java.sql types. Immediately convert to java.time classes. An Instant is a moment on the timeline in UTC with a resolution of nanoseconds.
Instant instant = ts.toInstant();
Notice that all the moving parts are in UTC: database storage, JDBC, java.sql.Timestamp, and Instant. No time zone complications at all.
Adjust for México
For the customer in Mexico, apply the time zone that they choose or that you assume is appropriate.
ZoneId zdt_America_MexicoCity = ZoneId.of( "America/Mexico_City" );
ZonedDateTime zdt_America_MexicoCity = ZonedDateTime.ofInstant( instant , zdt_America_MexicoCity );
Search Stack Overflow for info about generating strings that are automatically localized into human language and cultural norms by using DateTimeFormatter class and its ofLocalized… methods.
Adjust for Singapore
Ditto for the customer in Singapore.
ZoneId zdt_Asia_Singapore = ZoneId.of( "Asia/Singapore" );
ZonedDateTime zdt_Asia_Singapore = ZonedDateTime.ofInstant( instant , zdt_Asia_Singapore );
All three objects, our instant and pair of ZonedDateTime objects, represent the same simultaneous moment on the timeline.
Adjust for UTC
For the airline staff person working in UTC, use the Instant if all you need for a textual representation is ISO 8601 format with 0, 3, 6, or 9 decimal place digits for fraction of second.
String output = instant.toString();
If you need other formats as a textual representation, use the java.time.format package after converting the Instant to the more flexibly-formatted OffsetDateTime class. Note the use of the constant for UTC, stored in the subclass of ZoneId, ZoneOffset.
OffsetDateTime odt = OffsetDateTime.ofInstant( instant , ZoneOffset.UTC );
Adjust Data Input
If the user is inputting the flight time in UK time zone, adjust to UTC afterwards. By the way, do not confuse UK time with UTC. London time has varied over history, currently changing with Daylight Saving Time while UTC never varies (except leap seconds).
ZoneId zoneId_Europe_London = ZoneId.of( "Europe/London" );
ZonedDateTime zdt = ZonedDateTime( 2016 , 1 , 3 , 9 , 0 , 0 , 0 , zoneId_Europe_London );
Instant instant = zdt.toInstant();
java.sql.Timestamp ts = java.sql.Timestamp.from( instant );
Local
This Answer applies to specific moments, a specific date and time-of-day. If you meant flight times in the sense of "9 AM" by the clock on the wall which can move around because of anomalies including Daylight Saving Time (DST), then that would be another discussion. The Question said the user is entering a specific date and a specific time so the discussion above applies.
