Stream: implementers
Topic: Date http header for timezone
Angus Millar (Sep 19 2018 at 04:33):
I'm confused as to how I can express the timezone in the 'Date' Header as per this statement in the spec: http://build.fhir.org/http.html#return "Server should always return the default timezone for date searches in the HTTP Response headers using the Date header."
My reading of the 'Date' HTTP header format is that it must always be GMT, so how does that tell someone the default timezone unless it is mandatory that default always be GMT?
"Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time."
Ref:https://chat.fhir.org/#narrow/stream/4-implementers/search/server.20timezone.20header
An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC). The first two formats indicate UTC by the three-letter abbreviation for Greenwich Mean Time, "GMT", a predecessor of the UTC name; values in the asctime format are assumed to be in UTC. A sender that generates HTTP-date values from a local clock ought to use NTP ([RFC5905]) or some similar protocol to synchronize its clock to UTC.
Ref: https://tools.ietf.org/html/rfc7231#section-7.1.1.1
Grahame Grieve (Sep 19 2018 at 06:44):
........ and I don't know
Lloyd McKenzie (Sep 19 2018 at 13:25):
Sounds like a change request is in order. @Angus Millar, can you submit one?
Jenni Syed (Sep 19 2018 at 17:18):
See Also GF#16550
Jenni Syed (Sep 19 2018 at 17:18):
It looks like Grahame submitted some changes, but not sure if it addressed concerns around the term "time zone" and how it's used in the spec
Jenni Syed (Sep 19 2018 at 17:19):
but that Gforge did deal with the date header (at least there was some discussion of that in comments)
Jenni Syed (Sep 19 2018 at 17:31):
but I think I also was looking at the wrong date format on that :) Didn't realize it specifically required GMT
Grahame Grieve (Sep 21 2018 at 03:30):
well, the comments assumed that the date header did indicate the timezone
Grahame Grieve (Sep 21 2018 at 03:31):
as did I
Grahame Grieve (Sep 21 2018 at 03:31):
@Jenni Syed I don't understand something from your comments:
Grahame Grieve (Sep 21 2018 at 03:31):
Time zone != offset. We've had issues in prod where the offset is ambiguous and the wrong time zone was chosen. This comes into play more on "math" on dates than direct comparison
Grahame Grieve (Sep 21 2018 at 03:32):
that doesn't make sense - if you use timezone, and the offset is ambiguous, then you can have maths problems (been there, done that). That's why offsets are better.
Grahame Grieve (Sep 21 2018 at 03:32):
there's an extension for timezone
Grahame Grieve (Sep 21 2018 at 03:41):
though, of course, the subject here is really http headers, not extensions
Grahame Grieve (Sep 21 2018 at 03:42):
so the thing is that this candidate normative statement is simply wrong:
If the server has a default timezone, it SHOULD return the default timezone in the HTTP Response headers using the "Date" header.
Grahame Grieve (Sep 21 2018 at 03:42):
I would very much not like the whole ballot process to fail on this issue. But I would also like to fix this. Perhaps we can adjust the text to :
Grahame Grieve (Sep 21 2018 at 03:52):
If the server has a default timezone, it SHOULD return the default timezone in the HTTP Response headers using a XXX header.
Grahame Grieve (Sep 21 2018 at 03:52):
I just wrote to the chair of the HTTP WG asking him for comment....
Grahame Grieve (Sep 21 2018 at 03:52):
but I think we can change that text as a technical correction because no one can conform to it at all now
Jenni Syed (Sep 21 2018 at 16:13):
@Grahame Grieve For math, I mean things like calculating dose times in the future or from a date. Offsets don't work for this, timezones are the only thing that will have all the DST rules so that you can land things at the correct local time. This is true of things that have to happen at 8/20 as well as "weird" intervals.
Example of weird intervals: we have situations where a med is every 2 hours, but when it crosses DST, that isn't treated as a hard interval, it's flexed either to continue with previous times (which is weird, you ask "then why didn't they make it times of day" ... :) ) or actually be the hard 2 hours (and so the "time of day" will change). If it's the hard 2 hours, you're correct, the exact time zone probably doesn't matter. But if the goal is to maintain local time, it is important to get the correct time zone.
Jenni Syed (Sep 21 2018 at 16:15):
The other place getting the correct time zone matters is for display to the user. We have systems that cross time zones, and have requirements for some situations to display some times in the local users zone, and other times in the zone in which they were recorded - we actually record the time zone. We've already had 1 scenario which had a med passed in with an ambiguous offset via FHIR. When it displayed to the user, the wrong time zone was chosen, and it was reported by the user.
Grahame Grieve (Sep 21 2018 at 22:04):
ok that's clearer. I wonder whether this is something to add to the resource in meta - the timezone of the local user for the resource?
Angus Millar (Sep 25 2018 at 03:21):
Is there a reason not to add the server timezone to the servers CapabilityStatement at [base]/metadata?
Jenni Syed (Sep 25 2018 at 12:45):
@Angus Millar In our case, our server is always UTC, but the data is not the same and varies by the location of the user and patient.
Angus Millar (Sep 26 2018 at 03:10):
So which problem are we trying to solve, I see two problems.
1. How do I know a servers timezone, the FHIR standard does not state that UTC is mandatory for servers.
2. What is the timezone the resource creator was intending, if not supplied in a Date or DateTime.
Are these not both issues which each require different solutions.
Josh Mandel (Sep 26 2018 at 03:26):
ok that's clearer. I wonder whether this is something to add to the resource in meta - the timezone of the local user for the resource?
that'd be nice, for sure! I've been looking at http://build.fhir.org/extension-tz-code.html for this -- but it'd be nice not to have to say it separately on every datetime in a given resource, and it'd be nice to avoid extensions for this.
Josh Mandel (Sep 26 2018 at 03:27):
(Not necessarily "local user" but perhaps something more like "the timezone as which dates/datetimes in the resource should be interpreted")
Grahame Grieve (Sep 26 2018 at 05:15):
well, to pursue @Jenni Syed's answer.... at what level can you state the tz? can a resource contain mixed applicable timezones?
Josh Mandel (Sep 26 2018 at 14:28):
Right. If you have this kind of "default timezone context" flowing down from Resource.meta, and it gets overridden in extensions on specific datetimes... you have to be really careful about the whole thing.
Grahame Grieve (Sep 26 2018 at 14:45):
hmm
Grahame Grieve (Sep 26 2018 at 14:47):
I'm talking about an http header with the ietf http-wg. Not a lot of interest... seems they think it's a content issue, not protocol. Makes me lean towards adding timezone to meta. we could do an extension for R2-R4, and make it a core element in R5 if it proves useful
Jenni Syed (Sep 26 2018 at 17:34):
A bit of a brain dump trying to think through this...
Internally, we have some variation on how this is handled, and it depends on context. A specific date can have a zone tied to it. This is usually to capture context of the user that entered data, so that an app can choose to display that later. That would lean towards the extension. And I can see that this may not be 80% logic :)
In addition, we have a location that captures the local zone of the patient. This is so you can translate from a "local time" to a real instant in time correctly - like the med dosages. This is most common (for us) in inpatient scenarios. However, I would imagine that a consumer-facing app would need to do something similar when there is no encounter (for example) that would have a location tied to it. Note: we don't have a "zone" on the Location in FHIR, so another extension? Right now, someone would have to extrapolate this from geolocation, if it existed. (another option here would be to use the meta data like Grahame indicated so that non-encounter based as well as encounter-based zone info could be found in the same place)
Jenni Syed (Sep 26 2018 at 17:42):
Finally, we have apps where the use case makes more sense to convert all times to the local user's time zone. This is "client side" logic usually. From a server perspective, this isn't normally an issue it has to deal with except for the Narrative and other displays we return. I know we have a translation extension + the capability to add language tags to narratives now. It would be nice if I could only choose to return the "original" + the requested translation, and this is the main scenario I can think of that would start to push for headers
Jenni Syed (Sep 26 2018 at 17:42):
The assumption being that the "translation" would take Locale as well as zone preferences into consideration
Jenni Syed (Sep 26 2018 at 17:45):
But now we may be veering into uncharted waters :)
Grahame Grieve (Oct 01 2018 at 10:45):
comment form the chair of the HTTP WG:
This has come up a few times. While getting it into Web browsers would be difficult (thanks to the inherent privacy issues, as well as the existence of other solutions), defining it for non-browser applications simplifies the problem somewhat, and based on the number of times it's come up, might see some take-up.
Personally, I like the proposal in:
http://www.w3.org/mid/DBDF1A48B00F2042B20953D2ACE4968806A0ADE526@sha-exch14.shared.ifeltd.com
If you (or someone else) wanted to sketch out a proposal in an Internet-Draft, we could discuss it and decide whether there's consensus to adopt.
That said, the gating factor is likely to be finding someone who's willing to put in the work of editing a document. If we can find people to help in that process, would you be willing to do so?
Grahame Grieve (Oct 01 2018 at 10:45):
is anyone interested in taking this up?
Last updated: Apr 12 2022 at 19:14 UTC
