Stream: implementers
Topic: Date Header
Nathan Loyer (Apr 24 2020 at 16:08):
Hi, I have a question about returning the Date header for HTTP responses. https://www.hl7.org/fhir/http.html#return that page says "If the server has a default timezone, it SHOULD return the default timezone in the HTTP Response headers using the "Date" header." so it seems that we should be using whatever timezone our servers are using. However if you look at the spec from IETF (https://tools.ietf.org/html/rfc7231#section-7.1.1.2) it seems to be saying that the Date header should be in UTC/GMT. My team is debating whether to go with EST (which is unfortunately what many of our database date-times are stored in) or UTC. Does anyone know which we should be using?
Lloyd McKenzie (Apr 24 2020 at 18:15):
@Ewout Kramer
Grahame Grieve (Apr 24 2020 at 22:01):
I don't think there's a good answer to this question (or any other question involving time zones and HTTP).
I read the base HTTP specification several times trying to decide whether it mandates that the data must have a UTC header. I can't decide - it clearly says that the server must be able to correctly calculate the UTC time, but it doesn't explicitly say that it has to state it in that timezone
the HTTP committee is dedicated to demonstrating that timezone doesn't matter; they say that you should just use javascript (private communication between me and the HTTP chair MNot), but when you are delivering application functionality over an HTTP interface (which they also endorse) that doesn't cut it. But they've declined to actually endorse proposals for a timezone header....
Dunmail (Feb 03 2021 at 12:20):
Could the server publish it's TimeZone as part of the CapabilityStatement?
Grahame Grieve (Feb 03 2021 at 20:06):
it could. but it's the client timezone that's more useful in practice
Dunmail (Feb 04 2021 at 09:48):
Grahame Grieve said:
it could. but it's the client timezone that's more useful in practice
Our concern is that the server needs to know which timezone it is operating in when interpreting dates e.g. 2020-06-01T10:00 in the UK has daylight saving applied. There are scenarios where a client is operating in a different timezone to the server e.g. misconfiguration | different locale, and consequently the client and server interpret dates differently.
Where this is a risk, the client could at least check and amend behaviour accordingly e.g. translating date search parameters with implied precision into explicit date range searches.
Our internal solution will be to add an extension to CapabilityStatement.implementation but don't want to do this if there is a standard change in the pipeline!
Kevin Mayfield (Feb 04 2021 at 09:55):
duplicate respnse
Last updated: Apr 12 2022 at 19:14 UTC
