Server timezone best practice. UTC vs Local Time

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 :wink: but I would be interested in what is considered best practice, if there is such a thing?

4 Likes

@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.

2 Likes

Sounds like you better store UTC and then have an unstored calculated field to calculate time plus time zone difference.

2 Likes

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:

GetAsTime ( GetAsTimestamp ( Get ( CurrentTimeUTCMilliseconds ) / 1000 ) + ( Location::TimeAdjustment * 3600 ) ) returns 1:43:55.304 PM .

I am using the MBS plugin for the job. It also queries the client's time zone:

https://www.mbsplugins.eu/component_Time.shtml

I did not check how other plugins cover the topic.

2 Likes

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.

3 Likes

Thank you everyone for the replies. All very helpful, good suggestions. Also helpful for other people I hope.

@MonkeybreadSoftware Christian, I like the idea of grabbing the local time at login and referring to that. Thank you.

It seem like my instinct to leave the server on UTC is the best option.

1 Like

There are also date libraries that will let you handle timezones programmatically (from FMP). Don't know if that's an option for you.

... as long as you don't have users, who stay logged in over night when time zone changes.

And be aware that not all time zones use full hour difference.

2 Likes

Thank you - good points. I'll bear them in mind.

do you mean using APIs? Or JS Libraries?

libraries/APIs.

Links?
:stuck_out_tongue_winking_eye:

Not exactly sure what you need but here's a link to one API:


Here are python examples:

--

(tons of other examples with similar searches.)

There are also date libraries that will let you handle timezones programmatically (from FMP)

Thank you! I don't necessarily "need" anything, but your comment got me curious.

Edited: removed the link (I forgot it is a paid for API)

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."

4 Likes

All the APIs I use are totally free. If you can give me an example, I'll give you a timezone I generate. :slight_smile:

1 Like

Thank you for more helpful advice. All the comments here have been most helpful. Hopefully this will also be a useful resource for others.

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.

1 Like

Great Video! Every developer should watch this! :grinning:

1 Like

Sounds good.