Stream: implementers
Topic: GF#14673: allow timezone in date
Grahame Grieve (Feb 13 2018 at 21:21):
GF#14673 proposes that we relax the constraint "There SHALL be no time zone". MnM looks on this favorably, but 2 questions:
- is this a breaking change in theory
- is this a breaking change in prnciple. Specifically: does this break any reference implementationsa
Grahame Grieve (Feb 13 2018 at 21:23):
It requires changes to get the to support it, but it's not a big change for Java / pascal reference implementations. What about DotNet? swift? @Ewout Kramer @Brian Postlethwaite @Pascal Pfiffner @James Agnew (@Patrik Sundberg )
Brian Postlethwaite (Feb 13 2018 at 21:42):
The datetime already support timezone, so no extension needed there.
In the Australian context we have an extension for accuracy of the datetime. So you could put the complete value in there, and prove the accuracy indicator
Brian Postlethwaite (Feb 13 2018 at 21:49):
http://build.fhir.org/ig/hl7au/au-fhir-base/StructureDefinition-date-accuracy-indicator.html
Grahame Grieve (Feb 13 2018 at 21:50):
this really feels like something else to me
Brian Postlethwaite (Feb 13 2018 at 21:54):
The item is asking to mix date and datetime values in some user interface. Feels like a local interpretation issue. Not something for the spec to me.
Grahame Grieve (Feb 13 2018 at 21:57):
it's asking to allow timezone on date. the user interface stuff is requirements
Kevin Olbrich (Feb 13 2018 at 22:14):
@Grahame Grieve how would you propose representing a Date with a timezone?
Grahame Grieve (Feb 13 2018 at 22:15):
exactly per schema spec:
"date" : "2004-05-06Z"
Kevin Olbrich (Feb 13 2018 at 22:26):
In ruby, we would have to parse that as a DateTime and then convert it to a Date. Otherwise the timezone information would be ignored and parsing would not actually fail. I could see that being a source of some subtle bugs and would thus be a breaking change. However, in theory I don't think adding a timezone to a date and not requiring it is a breaking change from the semantic perspective.
Grahame Grieve (Feb 13 2018 at 22:27):
how does ruby handle schema dates otherwise?
Brian Postlethwaite (Feb 14 2018 at 01:31):
Is that an offset or time zone?
Eg +10:00 or australia/Melbourne
And only be there if the full date is provided?
Grahame Grieve (Feb 14 2018 at 05:50):
it's a timezone
Richard Townley-O'Neill (Feb 14 2018 at 05:58):
I thought that time zones were identified by offsets from UTC, not by names.
So Melbourne and Sydney are on AEDST (UTC +11:00), while Brisbane is on AEST (UTC + 10:00)
Richard Townley-O'Neill (Feb 14 2018 at 06:00):
https://en.wikipedia.org/wiki/List_of_time_zones_by_country
Grahame Grieve (Feb 14 2018 at 06:02):
yes we don't use names
Grahame Grieve (Feb 14 2018 at 06:02):
a few people use an extension for named timezone
Brian Postlethwaite (Feb 14 2018 at 08:28):
I'd personally suggest an extension, no native date format is going to handle this, and expect that will be the tz offset, not the actual time zone. Tied with the actual date, not being the names is fine.
We have some use cases with time only fields to associate a zone, so the when combined with a date can form a valid instant.
Also would be a potentially breaking change otherwise, validations ensuring length is ... Etc
Grahame Grieve (Feb 14 2018 at 11:16):
schema date allows this. So why would a native date not handle it? What would dot net do with a schema date with a timezone?
Jenni Syed (Feb 14 2018 at 15:33):
There's a noteable difference between offset and timezone
Jenni Syed (Feb 14 2018 at 15:33):
so may want to clarify that?
Jenni Syed (Feb 14 2018 at 15:35):
We've had issues in our system where we need a timezone and the offset is ambiguous.
Jenni Syed (Feb 14 2018 at 15:36):
but otherwise, I agree, it will be hard for us to parse this. We likely wouldn't allow this type of date either, since we wouldn't have a way to store it in our system.
Vassil Peytchev (Feb 14 2018 at 15:36):
XML Schema allows it, but is there an actual use case where it is significant? Isn't by definition the use of Date an indication that the precision of interest is 1 day, anything else is insignificant? As for .NET there is only a DateTime...
Jenni Syed (Feb 14 2018 at 15:36):
the question will be how hard it will be to 422 it vs. having the code just ignore the extra data. I would need to try out a few things :)
Grahame Grieve (Feb 14 2018 at 18:59):
the use case is in the task. Certainly if you weren't interested, you would drop it
Grahame Grieve (Feb 14 2018 at 19:00):
but DateTime doesn't do timezone anyway, so what's the difference for date?
Jenni Syed (Feb 14 2018 at 19:14):
In our system, we have the capability for most instants/dateTimes to store timezone and an offset. We do not have capability to store an offset for a date w/o time (and the libraries that we use to parse don't handle this type of data). We can, for some fields, store a date and time zone, but support for that is use case specific.
Grahame Grieve (Feb 14 2018 at 19:15):
so... you can drop timezone then...
Jenni Syed (Feb 14 2018 at 19:15):
Yeah, it just means I need to figure out how to do that properly with our date parsers, assuming that ignoring it is the acceptable path for FHIR
Jenni Syed (Feb 14 2018 at 19:16):
rather than failing it (either path, we would need to update our parsers - as of now, it looks like this gets interpreted as a time not an offset by default)
Grahame Grieve (Feb 14 2018 at 19:17):
it would have to be clear that systems are not required to preserve/round-trip the timezone part
Brian Postlethwaite (Feb 14 2018 at 19:26):
This is why i would suggest the extension, means every client has to hands it, not just ignore the extension for the case you have.
Another case may be using information elsewhere such as the location of the service our patient to drive zone.
Grahame Grieve (Feb 14 2018 at 19:36):
@Patrik Sundberg do you want to comment?
Kevin Olbrich (Feb 14 2018 at 22:16):
@Jenni Syed One possible way to handle this would be to parse it as a DateTime and then convert it to a pure date in the timezone your server is in. Then you wouldn't need to store the timezone/offset. In ruby it would be DateTime.parse(date_with_timezone).to_date.
Patrik Sundberg (Feb 15 2018 at 00:29):
I personally find it a bit odd that schema allows timezone offsets on dates (and times) but the fhir spec does not. I can think of multiple use cases where this information is valuable. But it would be quite concerning if a round trip store / retrieve to a fhir server was allowed to drop a provided timezone; I'm pretty sure that would cause bugs of various hard-to-diagnose kinds.
I personally would prefer the direct encoding ("2008-10-20+10:00") over an extension, since it's more natural, but if we do it that way then implementations would have to preserve it in their internal representations. I'll defer to the wisdom of the crowd as to whether the ship has sailed on making a change of that type.
While we're at it, I also think we should allow timezones on DateTimes consisting of only dates (the regex listed on the fhir datatypes page indicates that we don't currently), and possibly on times, though I don't personally need the latter right now.
Grahame Grieve (Feb 15 2018 at 00:33):
we don't allow several things the schema spec does, including leap seconds
Grahame Grieve (Feb 15 2018 at 00:34):
also, we don't ever say that servers have to round-trip faithfully. Yes, it's more reliable if servers do, but we live in the real world
Patrik Sundberg (Feb 15 2018 at 00:41):
Fair enough, leap second support is certainly quite low on my wish list. Guarantees similar to what exists (or not) for DateTimes with timezones should be sufficient.
So is the main concern implementations that would fail in some way (fail validation, for example) if they were to see a date with a timezone?
Grahame Grieve (Feb 15 2018 at 00:46):
yes, and whether the reference implementations show up any structural issues
Brian Postlethwaite (Feb 15 2018 at 02:53):
And any javascript code that handles the date will need to handle it (which is unlikely) where ignoring the extension for the rare case that its there is harmless.
Ewout Kramer (Feb 15 2018 at 15:29):
The .NET library internally keeps the dates as strings (since there is no native format to represent partial dates and datetimes) - forcing the library to express it as a .NET DateTimeOffset will do the "natural" thing, that is turn 2014-01-01+01:00 into 2014-01-01 0:00 +01:00.
So, I don't think this is a big change for the API.
Grahame Grieve (Feb 15 2018 at 20:27):
so I'm not sure where we stand on this:
- is it a breaking change in theory: probably not?
- is it a breaking change in practice: yes because most parsers will break, and there's downstream consequences
- do people like the change: mostly not so much, but few people have the requirement
Grahame Grieve (Feb 15 2018 at 20:27):
@Patrik Sundberg do you ever have the situation where the date timezone is different to the implicit timezone of the resource? Would it be better to mark the resource with a source timezone?
Richard Townley-O'Neill (Feb 15 2018 at 23:02):
Some thoughts
Date can be truncated to level of precision available: 2018, 2018-11, 2018-11-21
Time cannot, it must be to the second: 12:25:36
So imprecision in time is represented by using zeros, and should have another element to indicate that the zero is not significant, e.g. time="12:25:00", precision="h:m" or imprecision="-00:00:00+00:00:59"
DateTime with an unknown time is often done as date with zero for the time. This should have another element to indicate that the zero is not significant, e.g. dateTime="2013-06-08T00:00:00Z", precision="yyyy-mm-dd".
This allows time zones for DateTime with unknown time while accepting that time and date formats represent imprecision in different ways.
It does require us to confront imprecision in time.
Grahame Grieve (Feb 15 2018 at 23:04):
well, this is an orthogonal issue. We would prefer not to require seconds, but xml schema gives us no choice. No one has ever provided a use case for not having minutes.
Chris Grenz (Feb 16 2018 at 03:34):
XML schema allows it, but ISO 8601 does not as far as I can tell.
Patrik Sundberg (Feb 16 2018 at 11:18):
I can't currently think of a use case where timezones differ between date / datetime fields within a resource, but it doesn't strike me as impossible that it could happen.
I would prefer an extension on the primitive directly over an extension on the resource, to keep information local.
In practice, I think i'll make the protobuf implementation keep timezones for date/datetime/time, and parse from either the main value or from an extension, depending on how this thread pans out. I still would strongly prefer time offsets on the values though, extensions are a bit unwieldy.
Could we say that the SHALL won't apply until R4? Is that enough time to fix / test implementations? Or is this discussion already about R4, with R3 being frozen?
Grahame Grieve (Feb 16 2018 at 11:27):
we've always said that a date SHALL not have a timezone. this discussion is about relaxing it for R4. My read is that we don't have enough support to relax that, and it'll be an extension.
John Silva (Feb 16 2018 at 22:38):
@Grahame Grieve ?? I just went to the STU3 data types page and it says this; has this changed in R4?
"A date, date-time or partial date (e.g. just year or year + month) as used in human communication. If hours and minutes are specified, a time zone SHALL be populated."
I can't imagine NOT having a timezone unless FHIR prescribed that everything MUST be converted to UTC; otherwise, how do you deal with the 'hour between timezone switches'?
(There can also be use cases where the data is sourced in a different timezone from where the FHIR server is running or where the clinician is reviewing the data. I suppose it's up to some user interface to make the presentation of this date/time correct to the human viewer but how can computing algorithms work without knowing the timezone. For example, think about using observations to calculate daily intake and output totals.)
Grahame Grieve (Feb 17 2018 at 00:47):
date, not dateTime
Patrik Sundberg (Feb 19 2018 at 02:26):
@Grahame Grieve Since dateTime has become a bit intermingled in this thread, can we clarify whether timezone offsets are allowed on dates within the dateTime type? For example, are "2001+02:00" or "2010-01-02Z" allowed dateTimes? The wording on the stu3 data types page seem to indicate yes, since such patterns are allowed by xs:date and xs:gYear, but the provided regex says no. (I would like the answer to be yes)
Grahame Grieve (Feb 19 2018 at 02:30):
that would be an oversight on our part. The regex is the correct statement of our intent
Patrik Sundberg (Feb 19 2018 at 02:52):
That's unfortunate. In our internal profiles, we require timezones on all dateTimes, dates, and times. It's quite difficult and error-prone to properly convert these types to instants on a timeline without that constraint. This is especially true when dealing with data from various different timezones that are not the same as the local timezone.
Extensions work for this use case but it would be nicer if they were not quite so necessary.
Grahame Grieve (Feb 19 2018 at 02:55):
well, you could propose changing it, but judging by the discussion, it wouldn't get any different reception than the discussion we've already had
Last updated: Apr 12 2022 at 19:14 UTC
