Re: Questiona about timezones

Hi Grahame,

I think that your proposal is interesting. Can you please share some use
cases?

Adding a `Content-Timezone` means adding another representation modifier,
which has some implications when you have to audit request and responses.

The `Timezone` header instead seems to me overly complex.

Let me know,
R.


Il giorno lun 1 ott 2018 alle ore 12:54 Grahame Grieve <
grahame@healthintersections.com.au> ha scritto:

> ok thanks. I'm not sure I have the time personally. I'll ask around in the
> health standards community to see if there's anyone who wants to take this
> up and push it.
>
> Grahame
>
>
> On Mon, Oct 1, 2018 at 4:18 PM Mark Nottingham <mnot@mnot.net> wrote:
>
>> 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/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?
>>
>> Cheers,
>>
>>
>>
>>
>> http://www.w3.org/mid/DBDF1A48B00F2042B20953D2ACE4968806A0ADE526@sha-exch14.shared.ifeltd.com
>>
>> > On 26 Sep 2018, at 11:18 am, Grahame Grieve <
>> grahame@healthintersections.com.au> 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
>> 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 /
>> grahame@healthintersections.com.au / +61 411 867 065
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>
>
> --
> -----
> http://www.healthintersections.com.au / grahame@healthintersections.com.au
> / +61 411 867 065
>


-- 
Roberto Polli

*Full Stack DeveloperM. +39 3406522736*
·D

*TEAM PER LATRASFORMAZIONEDIGITALE*
*Presidenza del Consiglio dei Ministri*
teamdigitale.governo.it

Il Team per la Trasformazione Digitale, salvo eccezioni, comunica con le
altre Amministrazioni via posta elettronica ordinaria e non posta
elettronica certificata, in conformità a quanto previsto dall’art.47 del
Codice dell’Amministrazione Digitale.