medplum / medplum / 22237056785

92%

main: 92%

push

github

Fix scheduling ops during UTC/local day discrepancy (#8447)

For operations like `$find` and `$book`, there is an interesting edge
case: when the server is run in a different time zone (such as a server
in UTC and clients in the US), there is a window where the current
date in the server local time is different from the client date.

The original implementation of `eachDayOfInterval` naively used the date
component from the interval start without the time components, and so
wasn't shifting appropriately to the correct time when the timezone
information was added.

I've adjusted the implementation to begin by creating an exact
`Temporal.Instant` from the interval start date, and then using
`.toZonedDateTime(timezone)` to shift that into the desired timezone.
Finally, to keep the previous behavior of emitting start-of-day temporal
instances, we explicitly set the time components to zero with
`withPlainTime(...)`.

Implementation Note: Testing this is a bit of a chore. The test case as
written passes on my machine when run naively with `npm test`, because
Node defaults to running with the same time zone as the local system.
You can see the test fail by explicitly setting the process to be in a
different timezone: `TZ=utc npm test`. Ideally we should be able to test
different server/client timezone options, but adjusting the Node
timezone after startup seems to be more fraught than expected (see
packages like https://www.npmjs.com/package/timezone-mock for some
potential solutions).

For now I'm adding a test case that would reveal the problem in CI,
where tests are run with the system time set to UTC. In the long term,
we probably want a set of integration tests that spin up servers with a
variety of configurations, which would allow us to test multiple servers
with different timezones and compare their results. I'm deferring
building that into the future for now.

Fixes: https://github.com/medplum/medplum/issues/8417

Signed-off-by: Noah Silas <noah@medplum.com>

17302 of 19609 branches covered (88.23%)

Branch coverage included in aggregate %.

1 of 1 new or added line in 1 file covered. (100.0%)

31415 of 33157 relevant lines covered (94.75%)

13708.57 hits per line