Stream: implementers
Topic: Client Timezone
Bryn Rhodes (Feb 05 2019 at 02:35):
In discussing GF#16550 today on the FHIR-I call, we are wondering what implementers reaction would be to suggesting that clients SHOULD follow this IETF proposal (even though it is not a ratified standard HTTP header) to provide time zone information using the proposed Client Timezone header?
Michael Donnelly (Feb 05 2019 at 17:13):
I agree this is challenging.
Michael Donnelly (Feb 05 2019 at 17:15):
In the tracker, some people are talking about offsets and others are talking about time zones (and some about both). I agree with Jenni's point from 05 Jul 2018, and I think we need this to be about offsets and leave time zones out of it.
Michael Donnelly (Feb 05 2019 at 17:20):
@Bryn Rhodes I think that IETF proposal would add complexity that might not get us anything, but I might be looking at it wrong.
Option 1: The client says "give me all results after 2019-02-05T00:00:00-05:00"
Option 2: The client says "give me all results after 2019-02-05, and by the way, here are some extra headers letting you know that my offset it -05:00"
Is the latter enough easier for the client to make the additional complexity worth it?
Bryn Rhodes (Feb 05 2019 at 17:22):
Agree there is definitely confusion there, but this is specifically (and importantly) about timezones. Without the timezone, there's no way to reliably know what time it actually is where the request originated, which is important for questions like "is it past midnight?"
Bryn Rhodes (Feb 05 2019 at 17:22):
Offset alone doesn't give you that.
John Silva (Feb 05 2019 at 18:44):
And timezones change from country to country and year to year (typically because of law changes). Who would keep track of the history of timezone changes?
Michael Donnelly (Feb 05 2019 at 19:11):
What I'm saying is that the server doesn't necessarily need to know the client's time zone. If the client does a search with only a date (or with a date and time but no offset), the server needs to know what time the client thinks it is in order to give the client the results the client wants. But if the client provides the server with the explicit date, time, and offset in the search parameter, the server doesn't need to know what time the client thinks it is.
Michael Donnelly (Feb 05 2019 at 19:11):
I'm not saying that just to punt work from the server to the client; the client has to do work either way.
Michael Donnelly (Feb 05 2019 at 19:12):
Is it easier for the client to provide the necessary specificity in a header than it is for the client to provide the same specificity in a search parameter?
Jenni Syed (Feb 05 2019 at 19:14):
The timezone would be needed to translate from 1/2/2019 00:00 (essentially the timeless date/local date requested) to "midnight in my time zone"
Jenni Syed (Feb 05 2019 at 19:15):
Telling the time offset there won't let you know, for example, that a DST change just happened or will happen and you need to account for that in finding "midnight local"
Jenni Syed (Feb 05 2019 at 19:16):
@John Silva Usually, most libraries and OSs use the Olson database to track that: https://en.wikipedia.org/wiki/Tz_database
Jenni Syed (Feb 05 2019 at 19:17):
and if they don't, I feel it's a bit like the "don't roll your own crypto" saying. Don't roll your own TZ tracking... you're just asking for issues :)
Jenni Syed (Feb 05 2019 at 19:25):
And I think the only place where requiring the client to provide the exact offset/time becomes weird is where the date itself in the system is timeless/imprecise. Otherwise, I would think that best practice is for clients to fully qualify the time
Jenni Syed (Feb 05 2019 at 19:26):
Most of the time, when I've seen an app send in just a date (even for _lastUpdated), it's because they saw it in an example somewhere rather than they made a conscious decision to do it that way
Michael Donnelly (Feb 05 2019 at 21:05):
I hadn't thought of that (that using date only wouldn't be a conscious choice).
Morten Ernebjerg (Feb 06 2019 at 09:28):
My 5ct of implementer opinion on the initial question (for the statistics :smiley: ): I would rather not split the timezone information into a header (especially not a non-standard one). I would find it confusing to have a second place where timezone-related information can go and suspect it will lead implementers with questions about what should go where, whether double-encoding is OK etc. Also, what happens if the header info contradicts timezone information explicitly put in a date field or search variable? Finally, my feeling is also that, beyond the added technical complexity, moving info into headers always increases the potential for client errors due to misunderstandings or misreadings of the spec.
Grahame Grieve (Feb 06 2019 at 10:20):
date fields can always have different timezones from the system - they can't disagree. I don't think that it matters whether the timezone information is in a header or a parameter.
Grahame Grieve (Feb 06 2019 at 10:20):
I think it's not so much search where it matters, but things like narrative generation, appointment matching, decision support around care planning
Jenni Syed (Feb 06 2019 at 18:30):
Just to be clear: there is no where in FHIR today where you can communicate the time zone. The only thing that can be communicated is the offset of a specific time (and it may vary throughout a resource). Offsets are ambiguous (if trying to go to a unique time zone), and change within a given time zone during specific parts of the year or over time.
John Silva (Feb 06 2019 at 19:55):
Hmm, this same problem existed in the HL7 V2 world with the TimeStamp (TS) datatype and V2 has been dealing with this for ~30 years so I guess an elegant solution has still not been found ;-) [In the 'earlier' V2 days, and even now, the default is that if a timestamp doesn't have an offset the V2 processing rules say to interpret it as 'local time' -- whatever that means!! the sender's local time the receiver's or something else?]
Grahame Grieve (Feb 06 2019 at 20:25):
receiver's local time. MSH-7 timestamp has traditionally been used as the sender's timezone offset
Michael Donnelly (Feb 06 2019 at 23:21):
Getting back to @Jenni Syed's point above, does someone have a real world use case for this, and if so what is it they want to do?
Grahame Grieve (Feb 06 2019 at 23:31):
decision making on the server side.
Michael Donnelly (Feb 07 2019 at 00:18):
What's a specific example?
Grahame Grieve (Feb 07 2019 at 00:39):
@Bryn Rhodes
Bryn Rhodes (Feb 07 2019 at 00:55):
Hi @Michael Donnelly , I think a common example is scheduling an appointment. You really have to know the timezone in order to do that effectively. In decision support and quality measurement, there are cases where I'm looking for specific events to occur between admission and midnight on the admission date. If I'm running locally that's easy enough to tell, but as soon as I want to run that logic in the cloud, I can't answer the question, is it midnight where the request originated?
Bryn Rhodes (Feb 07 2019 at 00:57):
Note that I'm not suggesting this is something that all clients would have to do. There are plenty of cases that simply don't require it. But for cases that do require it, there ought to be a way to support the use case that's consistent, so that different implementations don't do it different ways.
John Silva (Feb 07 2019 at 01:05):
Another example is I/O totals in an acute care unit; these are normally calculated for the shifts based on the local time zone, but these could be calculated on a server in the cloud that 'lives' "who knows where" (or the server/service could be moved based on load). [To say nothing about the 'fun' problem of doing totals across the 'crazy hours' when the daylight saving time switches.] This same server/service could be used for different hospitals in a hospital group that are located geographically across different time zones.
Michael Donnelly (Feb 07 2019 at 13:54):
@Bryn Rhodes and @John Silva, both of those sound like cases where the client wants to refer to midnight in the server's time zone and/or in the time zone local to the department relevant to this resource rather than in the client's time zone.
Michael Donnelly (Feb 07 2019 at 13:54):
Am I thinking about this the wrong way?
Michael Donnelly (Feb 07 2019 at 13:58):
It seems like we have a few different potential problems that can contribute to these workflows having trouble:
1. Difference between the client's offset and the server's offset.
2. Difference between the server's offset and the offset of the department relevant to a resource.
3. Different between the server's current offset and the offset for a time zone (perhaps the server's, perhaps the client's, perhaps the department's) at the time (or, worse, times) relevant to the resource.
Michael Donnelly (Feb 07 2019 at 14:01):
2. Difference between the server's offset and the offset of the department relevant to a resource.
Examples include:
- Scheduling an appointment
- Decision support
- Quality measures
- I/O totals for acute care
Michael Donnelly (Feb 07 2019 at 14:02):
3. Different between the server's current offset and the offset for a time zone (perhaps the server's, perhaps the client's, perhaps the department's) at the time (or, worse, times) relevant to the resource.
Examples include definitely:
- Scheduling an appointment
- Quality measures
And maybe in some edge cases (operationally during Spring forward/Fall back)
- Decision support
- I/O totals for acute care
Michael Donnelly (Feb 07 2019 at 14:04):
If the client happens to be in the same time zone as the department for the resource, anything that solves potential issue #1 also solves #2.
Michael Donnelly (Feb 07 2019 at 14:05):
But if the client is somewhere else, things have actually gotten murkier.
John Silva (Feb 07 2019 at 14:44):
@Michael Donnelly -- well, in the example of I/O totals, it doesn't necessarily matter where the client is. I'll give an example, which might add ever further confusion but this is the reality with dealing with timezones ! (We can thank Ben Franklin for this!! http://www.webexhibits.org/daylightsaving/franklin.html)
My (Dr. Who) hospital is in the UK (London) but I'm traveling to the Eastern US and I get a call from the clinical staff about my patient. I need to look at my patient's chart. I use my VPN client to authenticate on my hospital's network, but I run a local web client to access the EMR system at the hospital. When I see my patient's data, even though I'm in the US, I need the data to be shown in the local (UK) time because that is what is going on with the patient. So, in this example, even though my web client is running in the US Eastern time zone, I need the data to be displayed in UK local time. (Also, what happens if the UK hospital's system is in the cloud and when I login I'm actually connecting to a cloud mirror in the US not the UK; which timezone should I expect to see?) You can think of a similar scenario for 'remote radiologist' reviewing imaging studies; e.g. patients in the US have imaging studies which are 'read' by radiologists in India (for example), does the remote radiologist want to see there local time or the time of the patient's location; I suspect the latter.
The idea here is that the source data typically needs to be stored in the time zone where the patient observation (event, etc.) happened. How this is viewed may not matter on where the client is located (and in which time zone) but I'm sure there are use cases where it might.
Michael Donnelly (Feb 07 2019 at 14:59):
I think we agree, @John Silva. What matters is where the patient is or where the encounter was or where a department is not where the client happens to be.
Nick Hatt (Feb 07 2019 at 15:09):
Yes @Michael Donnelly I've always thought that Location.position is the best place for timezone information to live . Maybe even adding a property to position for how people in that Location set their clocks, since working back from coordinates is not easy.
Jenni Syed (Feb 07 2019 at 17:27):
There is also some previous discussion around this on https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Date.20http.20header.20for.20timezone
Jenni Syed (Feb 07 2019 at 17:27):
The client time zone (app) is also important for narratives and places where dates are calculated by the server for display/"localization"
Jenni Syed (Feb 07 2019 at 17:28):
So, Facility time zone, patient time zone (may be the same as facility if the patient is at the site), client time zone/app time zone
Jenni Syed (Feb 07 2019 at 17:29):
I feel like app comes into play as well for the timeless searches on date... the spec right now says the server will use local, but I think that's really surprising/apps don't think of it that way
Jenni Syed (Feb 07 2019 at 17:29):
And when your server is cloud or has multiple timezones in a single instance... that you're searching over, it gets even more confusing
Michael Donnelly (Feb 07 2019 at 18:16):
Ah, I hadn't thought about display localization, @Jenni Syed .
Michael Donnelly (Feb 07 2019 at 18:18):
What I was getting at above is that knowing the time zone of the client doesn't address any of the cases @Bryn Rhodes and @John Silva gave above.
John Silva (Feb 07 2019 at 18:39):
Yes, I think both server and client side time zone information is necessary in certain use cases.
Another related question; how do you store the times on the server (e.g. effectiveDateTime)? If we store it "normalized to Zulu/UTC", then we handle the 'instance in time" and help with the problem with the spring forward/fall back issues but lose track of the local time that the event occurred. Take a simple example, if a baby was born at 12:01AM local time their birthday would be that date, but if someone looks at this date/time in UTC how would they know? (Yes, that's why Patient.birthDate is only date but there are cases we need to record birth date and time, e.g. to distinguish multiples, neonates where time is very important, etc.) Also, in the previous example, what would the remote doctor expect to see for I/O data or radiology reports that were stored in another time zone yet being shown on their client display? (think about the added problem if this is historical data and the time zone information changed since the data was recorded.)
Brian Postlethwaite (Feb 07 2019 at 21:59):
The other use case is a location or healthcare services opening hours.
As @Michael Donnelly pointed out it's basically the timezone of the location (and is what we've done calculations from in the past where no info is available). This zone is on time (no date) as the datetime is generated for each day as needed.
Brian Postlethwaite (Feb 07 2019 at 22:02):
And as everyone here have pointed out, there are many considerations at play, the local app/browser zone is just one of them, and can play a part in formatting a display for the user.
Grahame Grieve (Feb 08 2019 at 04:52):
agree that the thing that matter is the timezone of the user of the client; generally, we've been conflating those but it's not always the same
Grahame Grieve (Feb 08 2019 at 04:52):
on my server, I store as received, but index on UTC
Last updated: Apr 12 2022 at 19:14 UTC
