The SynCommons.pas unit features the TSynTimeZone class, which is able to retrieve the information from the Windows registry into memory via TSynTimeZone.LoadFromRegistry, or into a compressed file via TSynTimeZone.SaveToFile.
Later on, this file could be reloaded on any system, including any Linux flavor, via TSynTimeZone.LoadFromFile, and returns the very same results.
The compressed file is pretty small, thanks to its optimized layout, and use of our SynLZ compression algorithm: the full information is stored in a 7 KB file - the same flattened information as JSON is around 130 KB, and you may compare with the official content, which weighted as a 280KB tar.gz... Of course, tzdata stores potentially a lot more information than we need.

In practice, you may use TSynTimeZone.Default, which would return an instance read from the current version of the registry under Windows, and would attempt to load the information named after the executable file name (appended as a .tz extension) on other Operating Systems.
You may therefore write:

 aLocalTime := TSynTimeZone.Default.NowToLocal(aTimeZoneID);

Similarly, you may use TSynTimeZone.UtcToLocal or TSynTimeZone.LocalToUtc methods, with the proper TZ identifier.

You would have to create the needed .tz compressed file under a Windows machine, put this file together with any Linux server executable.
On a cloud-like system, you may store this information in a centralized server, e.g. via a dedicated service - see Client-Server services via interfaces - generated from a single reference Windows system.
The main benefit is that the time information would stay consistent whatever system it runs on.

Your User Interface could retrieve the IDs and ready to be displayed text from TSynTimeZone.Ids and TSynTimeZone.Displays properties, as plain TStrings instance, which index would follow the TSynTimeZone.Zone[] internal information.

As a nice side effect, the TSynTimeZone binary internal storage has been found out to be very efficient, and much faster than a manual reading of the Windows registry. Complex local time calculation could be done on the server side, with no fear of breaking down your processing performances.

Feedback is welcome, as usual, on our forum; and you would find out the updated version of this blog article within our online documentation!