Subject: Questiona about timezones

From: Grahame Grieve <[email-masked]>
Date: Wed, 26 Sep 2018 11:18:27 +1000

Hi

We've run into a problem with the FHIR HTTP API to do with timezones (FHIR
= HTTP API for healthcare). TImezones are hard to deal with, and we can't
nail everything down (duh!). There's cases where the server needs to know
the client's timezone to perform certain tasks correctly on behalf of the
client, and the client wants to know the server's timezone to fully
understand certain outputs

The classic response is for this to be handled by javascript client side,
but that doesn't work for a data (json) API. Note also that in principle,
servers should not have a timezone, but in practice, every clinical system
in the world does have a timezone, and it matters a whole lot. If we care
about legacy data, we have to have the client knowing what the server
defaults to... and we really care about legacy data. And various clinical
protocols have operational ties to timezones, not just offsets (giving
medications at the right time really does matter)

Has anyone got any comments on this?

I like the header described in
https://tools.ietf.org/html/draft-sharhalakis-httptz-05 and would specify
it for both directions, but that's not blessed by the http-wg?

Grahame

-- 
-----
http://www.healthintersections.com.au / [email-masked]
/ +61 411 867 065

---

From: Grahame Grieve <[email-masked]>
Date: Wed, 26 Sep 2018 20:58:36 +1000

whoops - slipped off the list :-(

> How do the system libraries dig out the information?
>
> For TZ information about one's own host, can you not use
> Intl.DateTimeFormat().resolvedOptions().timeZone gets you the
> information to pass in a form? and then on the server side there's
> datetime/DateTime (python/PHP, respectively) that you can build into
> HTML to be passed to client JS.  But again, that's HTML/JS that would
> have to be layered on top whatever JSON API you were building.
>

form variables. We could put it in the json.. but this degrades the
stability
of the json with what is context information

Some one else asked: geolocation - when correct - is not reliable anyway.
The web server might be a facade located differently from the actual
clinical
system, but the actual clinical system might also be located in multiple
timezones (e.g. multi-homed).

> We believe that we need a way for the client and server to communicate
> > with each other about their timezones, and we think that it should be
> > in the http headers. We're surprised that this hasn't come up more
> > widely...
>
> Ok.  That draft, of course, only goes in one direction

yes we would probably use it in both...

thanks
Grahame

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 1 Oct 2018 16:18:51 +1000

Hi Grahame,

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/[email-masked]

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?

Cheers,

http://www.w3.org/mid/[email-masked]

> On 26 Sep 2018, at 11:18 am, Grahame Grieve <[email-masked]> wrote:
> 
> Hi
> 
> We've run into a problem with the FHIR HTTP API to do with timezones (FHIR = HTTP API for healthcare). TImezones are hard to deal with, and we can't nail everything down (duh!). There's cases where the server needs to know the client's timezone to perform certain tasks correctly on behalf of the client, and the client wants to know the server's timezone to fully understand certain outputs 
> 
> The classic response is for this to be handled by javascript client side, but that doesn't work for a data (json) API. Note also that in principle, servers should not have a timezone, but in practice, every clinical system in the world does have a timezone, and it matters a whole lot. If we care about legacy data, we have to have the client knowing what the server defaults to... and we really care about legacy data. And various clinical protocols have operational ties to timezones, not just offsets (giving medications at the right time really does matter)
> 
> I like the header described in https://tools.ietf.org/html/draft-sharhalakis-httptz-05 and would specify it for both directions, but that's not blessed by the http-wg?
> 
> Grahame
> 
> -- 
> -----
> http://www.healthintersections.com.au / [email-masked] / +61 411 867 065

--
Mark Nottingham   https://www.mnot.net/