What is UTC? And Why Does it Matter for Applications?
When building FileMaker Applications, we often encounter solutions that require the use of time, time zones, daylight savings time, and possibly UTC. UTC stands for Coordinated Universal Time, and it’s adjusted by a certain offset depending on the time zone. Many APIs and database processes use UTC to communicate time and it’s important that we consider this carefully while developing.
Here are a few real-world scenarios that you might come across, and some great resources to help you tackle them.
Users in Different Time Zones
When working with time or timestamps in a FileMaker solution, you may have users that reside in different time zones from one another, or a different time zone than the server on which you host the database files themselves. With the growth of cloud servers and virtual machines it can be more common than ever for the server time to vary from a user’s local time. If you’re capturing time or using it to make comparisons, you’d want to use the same measuring stick for all users.
Universal time or the host time would be a good reliable way to capture time independently of a user’s time zone, as you’ll likely want to be able to rely on the sequence of information in your data and have a standard way to capture and evaluate timestamps in comparison to one another. Furthermore, if you have processes that are running on the server and they’re being time-compared against a user’s processes, you’ll want to make sure that you’re using reliably comparable time in both scenarios. When comparing user timestamps to a host that is using UTC you can define a Modification Date (Host) by using the Get(CurrentHostTimestamp) function and referencing your default modification timestamp to trigger the field to evaluate.
Daylight Savings
Let’s say you’re setting up a database to communicate with Google Calendar. You determine that your users are in the Central Standard Time time zone, which is six hours behind Coordinated Universal Time, so you set your offset as -6:00. However, when daylight savings time rolls around your users’ events would now be an hour behind! You could manually adjust the UTC offset to -5:00 but perhaps there’s a better way to solve this dynamically.
For the Google calendar problem, the solution was to edit the call and send the time zone instead of hardcoding the UTC offset. If your solution does not have a way to automatically account for the time zone or daylight savings offset, you could verify that information using the Google Time Zone API that will return the information you need to calculate the offset in real-time. Pun intended.
Resources
APIs that return time zone offsets:
After gaining experience with UTC and time zones it will become second nature to account for common outliers. If overlooked they can cause real trouble for your time-based systems.
