I have set-up and use FileMaker server in-house for many years for a small company (in Germany) and never worried about the server timezone. It is local, it is in-house, nobody works at night when the clocks change. I never had any issues.
But now I am trying to build a FileMaker App which may become a vertical market solution, and I am not sure what the best practice for the Server Time Zone is?
UTC seems like the best choice for me - but involves more work, if I want to use Get(CurrentHostTimestamp). Local time, for the users, seems easier, but I am worried about summertime / wintertime causing inconsistency in system timestamps.
I do have a plan but I would be interested in what is considered best practice, if there is such a thing?
@BenMiller saved ≠ displayed: I would store UTC times and make sure users see the times appropriate for their time zone in each case. This requires some effort. However, in my opinion, this is necessary so that users do not have a negative experience with it.
[Edit:] Or you store both times. UTC for the application to work properly and local time for display purposes.
Interesting question. I’ll have a look to that too.
Important topic, thanks for bringing it up, @BenMiller.
Here's FM's approach (copied from FMP Help):
Calculates the local time for the specified time zone. When the time in UTC is 08:43:55.304 and TimeAdjustment contains -7:
It may be an acceptable optimization to query the time zone difference to UTC only on start of solution and keep it in a global variable at all time for quick access.
MBS( "Time.TimeZoneOffset"; 0 ) is what our plugin queries from the OS and uses internally.
For this topic... I would watch the below video first, and make sure you know what problem you are trying to solve. Is it necessary to solve one problem, or are you really trying to just give the user a sense of the timeframe? How exact is acceptable? Is your app being used across multiple timezone?
If the user needs to know, this thing happened 12 hours ago, then you only need to solve that use-case. Typically, I would store the UTC and Server timestamp. That typically gives me enough data to calculate what I need.
Also remembering that UTC, unless you are retrieving it from the server, is based on the client time. If the client time is wrong, or they move into a different timezone, and their clock hasn't updated yet...well, you get the idea.
Server timestamp gives you a central point to work from. "This event happened n minutes/hours/days ago."
Thank you @OliverBarrett for the links and advice. I don't have a specific problem I need to solve at the moment with a service or API call. But I may want to use that in future. The OP was a general question, which happily has produced some great answers. For now I can do what I need to do in FM. The server clock will be set UTC, user display will take into account the user timezone. All mission critical timestamps will be in UTC hidden from users. I feel comfortable this will work well.