Stream: fhirpath
Topic: DateTime with timezone but without time?
Paul Lynch (Jun 12 2019 at 14:50):
The grammar for the May ballot permits DateTimes like "@2019T-04:00". Is that desirable? What would that mean?
Grahame Grieve (Jun 12 2019 at 15:39):
I don't think it's meaningful
Paul Lynch (Jun 12 2019 at 19:36):
@Bryn Rhodes Should I file a tracker item to remove that possibility?
Lloyd McKenzie (Jun 12 2019 at 21:10):
I think the intention was to support full dates with timezones - because sometimes that is relevant. Might be reasonable to prohibit for just yyyy or yyyy-mm. It would be a breaking change though, so we'd need to check that prohibiting it wouldn't negatively impact anyone.
Paul Lynch (Jun 13 2019 at 14:00):
The published STU1 fhirpath grammar does allow you to stick a Z at the end of a partial date, but if you want any other time offset, you have to specify a full date and include at least an hour. So, the breaking change would be to not allow Z, specifically, at the end of a DateTime without at time.
Bryn Rhodes (Jun 17 2019 at 19:15):
The intent was to only allow timezone as part of a DateTime that included a time, but yes, the way that it was defined it allowed timezones. @Grahame Grieve, @Ewout Kramer, @Brian Postlethwaite, do your implementations accept the date time literal @2019T-04:00?
Brian Postlethwaite (Jun 17 2019 at 22:32):
Has someone come up with an example of a fhirpath expression where you want to use the value.
Bryn Rhodes (Jun 18 2019 at 01:14):
I'm not suggesting it's a valid literal, I'm just surveying current implementations for behavior.
Ewout Kramer (Jul 08 2019 at 08:31):
I am sure I don't accept that.
Paul Lynch (Jul 09 2019 at 17:19):
I created GF#22818 for this issue.
Bryn Rhodes (Aug 13 2019 at 01:32):
I've proposed a resolution for this (GF#22818) and (GF#22989). Please poke holes in it, I'm adding it to a block vote for consideration on the 8/20 ITS call. @Paul Lynch , @Ewout Kramer , @Chris Moesel
Ewout Kramer (Aug 13 2019 at 09:51):
Looks fine to me!
Paul Lynch (Aug 13 2019 at 14:22):
In general the resolution looks good, but the timezoneoffset pattern differs from the FHIR pattern: (Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00)). The proposed FHIRPath pattern, ('Z' | ('+' | '-') [0-9][0-9]':'[0-9][0-9]), allows timezone offset values like +99:99 that FHIR does not. Is it possible to just copy the FHIR pattern?
Bryn Rhodes (Aug 13 2019 at 17:26):
In the parser for a language though, putting validation like that in the lexer makes parsing much more difficult, because what it ends up meaning is that +99:99 is not _tokenizable_. We've purposely defined the regexes here to be more broad, leaving semantic validation to the parser.
Paul Lynch (Aug 13 2019 at 17:50):
I think I would rather have the lexer handle as much as possible than have to write code to further validate its output. But, I guess the intent is to avoid the ugly ANTLR error messages in favor of custom ones written for the parser?
Ewout Kramer (Aug 19 2019 at 09:16):
Yes, that certainly helps, not just in ANTLR but any framework where lexing, tokenizing and grammars are separated. I had to get used to it, but it does get you better error messages. Also, you can never get to the bottom of it anyway (think leap years), so why have part of the validation in the lexer and part in the higher-level parser? And in a "term" rule, it's really useful that a parser would at least grasp that you are trying to specify a date - rather than saying "it's none of the rules in term, so you're totally off". Even in smart hand-written parsers you'd need something to recognize "almost correct dates" to give sensible error messages?
Last updated: Apr 12 2022 at 19:14 UTC
