Time zone system setting

Development
1

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

2

Would this be a Location time zone?

3

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

4

And we have location attributes :muscle:

5

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

6

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.

7

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

8

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.

9

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.

10

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

11

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

12

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.

13

“The server time contains no time zone information; only an offset”…the server does have a time zone set.

Oh yeah, I was just wrong about that :slight_smile:

14

I think the most important feature in support of timezones is to ensure that we stop using relative times (i.e., times without an associated timezone) anywhere.

In other words, we could…

  1. Have a global property that define’s the “system’s default timezone” (when this global property doesn’t exist, we use the server’s – hardware – timezone)
  2. We begin converting all references to relative time (without timezone) to absolute time (including timezone) and any cases where the timezone is missing, we use the system’s default timezone. This includes both API changes and refactoring all times in the database to go from datetime (without timezone) to timestamps (with timezone).
  3. We strive over time to reduce the number of places where we need to use the system’s default timezone until its no longer needed for the platform (i.e., all API calls use absolute times & assume UTC if timezone not specified and there are no more timezone-less times inside the platform).

For the use case for location-specific timezone overrides, we could still use an attribute of Location to handle those cases.

15

It would also be a good idea to move the backend to use the java.time classes instead of java.util.Date, etc as java.util.Date only has an implicit timezone (which is part of how we ended up in this situation).

1 Like