Re: Questiona about timezones

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:

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?


> On 26 Sep 2018, at 11:18 am, Grahame Grieve <> 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)
> Has anyone got any comments on this?
> I like the header described in and would specify it for both directions, but that's not blessed by the http-wg?
> Grahame
> -- 
> -----
> / / +61 411 867 065

Mark Nottingham

Received on Monday, 1 October 2018 06:19:18 UTC