Stream: fhirpath
Topic: Default timezone offset?
Bryn Rhodes (Jan 28 2019 at 00:56):
In reconciling test results from different engines, the question of a default timezone offset has come up. The spec currently says if a date/time value doesn't have a timezone offset, use the timezone offset of the evaluating environment. But this is potentially a policy decision, so we'd like to get input on the question (GF#20311).
Bryn Rhodes (Jan 28 2019 at 00:56):
We're also looking at removing the timezone offset from Time values (GF#20310).
Grahame Grieve (Jan 28 2019 at 01:37):
In a server context, I find default timezone problematic
Paul Lynch (Jan 28 2019 at 18:01):
We're also looking at removing the timezone offset from Time values (GF#20310).
I am neither for it nor against, but I am not sure I follow the reasoning. It says "the timezone offset is ambiguous because it does not provide enough context to determine the timezone". If someone writes, @T11:00-07:00, does it matter which timezone is -7?
Grahame Grieve (Jan 28 2019 at 19:19):
Bryn's advanced use case was a repeating event that happens every day at 15:00+05:00. And there, it does matter
Grahame Grieve (Jan 28 2019 at 19:19):
because oes it change with timezones?
Paul Lynch (Jan 28 2019 at 19:47):
As I understand it, "15:00+05:00" specifies a moment in time, irrespective of timezone-- the moment that can also be expressed as "10:00Z".
Grahame Grieve (Jan 28 2019 at 19:53):
it can't specify a monet in time, since it has no date.
Paul Lynch (Jan 28 2019 at 19:56):
True. A moment that occurs every 24 hours, then. My question is how a timezone can affect the meaning "15:00+05:00". The offset is already known.
Grahame Grieve (Jan 28 2019 at 19:58):
because usually, at least, people actually mean a timezone rather than an offset. As I am all too familiar with, since HL7 calls are a moving target for me. They happen at a time in a timezone, rather than at an offset time
Grahame Grieve (Jan 28 2019 at 19:58):
I don't know of anything that happens at an offset
Jean Duteau (Jan 28 2019 at 19:59):
The problem is that many times events are expressed in a timezone whose offset changes based on the date. So Eastern Time is either EST or EDT and has a different offset.
Paul Lynch (Jan 28 2019 at 20:13):
@Jean Duteau So, that would cause a problem is someone wrote, "15:00 ET" (Eastern Time), because the offset would in that case depend on the date. But, I think what is under discussion is the whether it will permitted to specify an offset with just a time, like "15:00-05:00". You might not not know whether that that -05:00 is ET time or not, but you know it is 5 hours behind UTC.
Jean Duteau (Jan 28 2019 at 20:20):
(helps to go read the tracker item) I now agree with what you are saying. The tracker seems to imply that I want to take the timezone offset and convert it back to an actual timezone. I would argue that you can't do that even if you have a date, because -05:00 can be any number of timezones even for a given date. So that problem of converting to a timezone seems out of scope of the Time datatype and thus wouldn't be an argument for-or-against the offset. As well, Grahame and my original answer also seem to be out of scope since that's not what the timezone offset is for. If I have a time expressed as "15:00 ET", I'm hooped with the existing time and date datatypes because that isn't one specific offset.
Bryn Rhodes (Jan 28 2019 at 20:56):
The proposed disposition is I think to remove the timezone offset from the Time type because of the ambiguity (the same approach the FHIR Time type takes).
Paul Lynch (Jan 28 2019 at 21:01):
@Bryn Rhodes We were just discussing what the "ambiguity" is, and how removing the offset helps. The questions are 1) What is ambiguous about "15:00-05:00", and 2) How is "15:00" less ambiguous?
Grahame Grieve (Jan 28 2019 at 21:38):
I don't think it's ambiguous. I just think it's uselss
Paul Lynch (Jan 28 2019 at 22:05):
I can't say how useful it is, but if you have a stream of data you're reading and a subset of it is from a person at offset "-05:00", that gives you some rough idea of where the person is (possibly), and whether (for example) the person is likely to see an email or be reachable by phone at a particular time.
Joel Schneider (Jan 28 2019 at 22:09):
Offset becomes tricky when considering locale-dependent augmentations such as U.S. daylight saving time, European summer time, etc. Would the addition of server locale metadata make the offset more useful?
Brian Postlethwaite (Jan 28 2019 at 22:10):
Is not ambiguous, it's pointless.
If you want to fix a regular time (which is the common case), you need the zone, not offset. E. G. 9:30 america/new york
Brian Postlethwaite (Jan 28 2019 at 22:11):
With that you can construct the real intended date time for any specific date correctly.
Brian Postlethwaite (Jan 28 2019 at 22:13):
This is what we need in the HealthcareService resource for availability. I think this is still in a tracker and not applied yet.
The binding would be to the tz database
https://en.m.wikipedia.org/wiki/Tz_database
Paul Lynch (Jan 28 2019 at 22:24):
Thanks, @Brian Postlethwaite , for pointing out the "common case". (I was thinking of other cases, but they are probably not realistic.)
Bryn Rhodes (Jan 29 2019 at 03:13):
For defaulting timezone offset, options are: 1) don't default at all, or 2) default to the timezone offset of the server, or 3) default to the timezone offset of the request. In CQL, we use option 3. It's not perfect, but it's more likely to give the expected answer than converting to UTC.
Bryn Rhodes (Jan 29 2019 at 03:14):
We also use the timestamp of the request for the now() and today() functions. GF#20312
Bryn Rhodes (Jan 29 2019 at 03:18):
The FHIR spec suggests option 2 (but also cautions, here there be dragons)
Brian Postlethwaite (Jan 29 2019 at 03:27):
Where do you pull it from in the request?
Bryn Rhodes (Jan 29 2019 at 03:32):
We don't specify that, but have suggested the Date header for http requests.
Paul Lynch (Jan 29 2019 at 15:27):
We don't specify that, but have suggested the Date header for http requests.
@Bryn Rhodes It sounds like you are thinking of server-side evaluation of FHIRPath. For client-side evaluation (e.g. in the context or rendering/updating a Questionnaire) what would the "request" be, from which one would get the default timezone offset? Maybe in that case since it is client side, it would just use the client's (browser's) timezone offset?
Bryn Rhodes (Jan 29 2019 at 16:14):
Yes, that's how I tend to think about it, even for client-side evaluation, there's still a "call" to the engine, and that's where you would pass the "request" time. In a browser, using the browser's current timestamp.
Paul Lynch (Jan 29 2019 at 16:17):
That should work.
Grahame Grieve (Jan 29 2019 at 20:38):
what's the timezone of the request?
Bryn Rhodes (Jan 29 2019 at 21:35):
Timezone offset of the request
Grahame Grieve (Jan 29 2019 at 21:39):
really? where is that?
Bryn Rhodes (Jan 29 2019 at 21:41):
Not sure what you mean?
Grahame Grieve (Jan 29 2019 at 21:47):
Unfortunately, there is no corresponding “Accept-Timezone” header- the HTTP standard does not contain any facility to allow the browser to automatically tell the server what time zone the user cares about.
Bryn Rhodes (Jan 29 2019 at 21:50):
Gotcha, and the Date header only allows communication of UTC. But that could be used to compute an offset on the server.
Bryn Rhodes (Jan 29 2019 at 21:51):
That you could then pass to the engine.
Paul Lynch (Jan 29 2019 at 21:57):
How do you compute an offset from a UTC date stamp without knowing the timezone in advance?
Grahame Grieve (Jan 29 2019 at 22:06):
you can't. all you can know is the server timezone. see https://tools.ietf.org/html/draft-sharhalakis-httptz-05, which never got up. I asked the http working group about it, and they said 'use javascript', as if restful apis were not a thing :-(
Bryn Rhodes (Jan 29 2019 at 22:20):
So it is possible, but it requires the client provide the request DateTime as a parameter. That's pretty important for decision support use cases, is it too much burden to require the client to provide it?
Grahame Grieve (Jan 29 2019 at 22:21):
lol I bet the answer is yes. You could ask on the implementer channel
Bryn Rhodes (Jan 29 2019 at 22:21):
Or is this a case where the spec could allow for a policy-based decision?
Grahame Grieve (Jan 29 2019 at 22:22):
what kind of policy baed decision in which spec?
Bryn Rhodes (Jan 29 2019 at 22:28):
I think there are two places in the FHIRPath spec where it matters, 1) What is the current date/time, and 2) Should date/time values that don't have a timezone offset specified use the timezone offset of the current date/time. Both those can be policy decisions based on the scenario, with the simplest being 1) local server time, and 2) no default.
Grahame Grieve (Jan 29 2019 at 22:47):
I think at the FHIRPath spec level, yes, that should be the rule
Bryn Rhodes (Feb 01 2019 at 06:38):
I've updated the dispositions for GF#20310, GF#20311, GF#20015, and GF#20312 based on this discussion.
Last updated: Apr 12 2022 at 19:14 UTC
