FHIR Chat · date searches · implementers

Stream: implementers

Topic: date searches


view this post on Zulip Ben Spencer (Nov 02 2017 at 17:08):

When searching by day, "For example, the date 2013-01-10 specifies all the time from 00:00 on 10-Jan 2013 to immediately before 00:00 on 11-Jan 2013" - but in what timezone?

view this post on Zulip Ben Spencer (Nov 02 2017 at 17:16):

I suppose whatever timezone the value on the resource is recorded with (if any)

view this post on Zulip John Moehrke (Nov 02 2017 at 17:24):

all timezones... ?

view this post on Zulip Brian Postlethwaite (Nov 10 2017 at 08:06):

This is only relevant when cross processing date values with date/time values.
For date/date comparisons, there is no time component, and hence no zone issue.

view this post on Zulip Brian Postlethwaite (Nov 10 2017 at 08:07):

If your storage layer is storing dates as datetimes, then yes you'd need to be careful here.

view this post on Zulip Christiaan Knaap (Nov 10 2017 at 08:18):

When the date parameter is not fully specified, matches against it are based on the behavior of intervals, where:
    Dates with only the year specified are equivalent to an interval that starts at the first instant of January 1st to the last instant of December 31st, e.g. 2000 is equivalent to an interval of [2000-01-01T00:00, 2000-12-31T23:59].
    Dates with the year and month are equivalent to an interval that starts at the first instant of the first day of the month and ends on the last instant of the last day of the month, e.g. 2000-04 is equivalent to an interval of [2000-04-01T00:00, 2000-04-30T23:59].
Where possible, the system should correct for timezones when performing queries. Dates do not have time zones, and time zones should not be considered. Where both search parameters and resource element date times do not have time zones, the servers local time zone should be assumed.

I think this means that the search parameter ultimately is always expressed as a datetime (either already on the url, or a date interpreted as a period by the server as described above), and to match that with the resources, I use datetimes in the search index as well. Thereby using the second rule: use the servers local time zone if not otherwise specified.

But I agree there are probably cases where these rules don't cover everything.

view this post on Zulip Brian Postlethwaite (Nov 10 2017 at 09:21):

For date parameters, I'm actually indexing the string.
(and therefore the starts-with works great, completely ducking the issues)


Last updated: Apr 12 2022 at 19:14 UTC