Time zone system setting

I’d like to suggest that we add a global property / system setting for time zone. There are cases where the time that should be shown to the user is the time at the clinic, regardless of the time zone that the client is currently in, such as with appointments. I think the only way to handle this is for the server to be able to communicate the clinic time zone to the client. Right now there are cases where the server time is used as if it is the clinic time, which is not a good way to handle this. When the client needs to render a date in the clinic time zone, it can request this system setting. Sound good? How should we go about doing that?

@mksd @mogoodrich @mseaton @ibacher @dkayiwa

Would this be a Location time zone?

Oh that’s a good idea. It probably should be associated with the location, shouldn’t it.

And we have location attributes :muscle:

But do we have a way of saying “if the implementation is using the appointments module, then locations need to have this particular attribute”?

Attributes can be used for implementations or modules to extend the core data model. In this case, if the feature is specific to the appointments module, it could look for the location attributes and use them if they exist, providing default behavior if they don’t exist.

If any core code (e.g., core functions of the Location API) depend on data, then we would want to adapt the core data model.

Seems like it might make sense to have both… a GP and location attributes, and when populating the session context with the “location timezone” it would look in the following places in this order:

  1. Timezone associated with the current session location
  2. Timezone associated with the “time zone” global property
  3. Timezone of the server itself

@mksd would be good to think about how this relates/helps with all the timezone refactoring you are doing.

Take care, Mark

The server time contains no time zone information; only an offset. For most servers in the world that offset is 00:00, because most servers use UTC. We should never use the offset from the server for anything.

That seems reasonable to me, @burke . In this case, this would mean that the appointments module would show clinic-localized times if the Location Attribute “time zone” exists, and show client-localized times otherwise.

@bistenes not sure what you mean? I understand the difference between timezone and offset, but on all our current servers a specific timezone is set… I believe you can fetch it with:

https://docs.oracle.com/javase/8/docs/api/java/time/ZoneId.html#systemDefault--

@mogoodrich Presumably that’s the time zone of the server, which is not a reliable proxy for the time zone of the clinic.

Agree that the time zone is not a reliable proxy for the time zone of clinic (though for best or worse it’s all we’ve had up until now, and what we’ve used)… I was just confused by “The server time contains no time zone information; only an offset”…the server does have a time zone set.