Date objects in query parameters are now serialized as time-zone-agnostic Unix timestamps (NNNNNNNNNN[.NNN], optionally with millisecond-precision) instead of datetime strings without time zones (YYYY-MM-DD HH:MM:SS[.MMM]). This means the server will receive the same absolute timestamp the client sent even if the client's time zone and the database server's time zone differ. Previously, if the server used one time zone and the client used another, Date objects would be encoded in the client's time zone and decoded in the server's time zone and create a mismatch.
For instance, if the server used UTC (GMT) and the client used PST (GMT-8), a Date object for "2023-01-01 13:00:00 PST" would be encoded as "2023-01-01 13:00:00" and decoded as "2023-01-01 13:00:00 UTC" (which is 2023-01-01 05:00:00 PST). Now, "2023-01-01 13:00:00 PST" is encoded as "1672606800" and decoded as "2023-01-01 21:00:00 UTC", the same time the client sent.
As far as I can tell, this is almost always the preferred behavior. Should a user need the old behavior, they can manually convert Dates to strings before passing them in as query parameters.
Both unit tests and integration tests pass. Because the client's time zone is now accounted for, the test cases use Date.UTC() so they pass even if the computer running the tests is not using UTC.
Checklist
Delete items not relevant to your PR:
[x] Unit and integration tests covering the common scenarios were added
[x] A human-readable description of the changes was provided to include in CHANGELOG
Summary
Date objects in query parameters are now serialized as time-zone-agnostic Unix timestamps (NNNNNNNNNN[.NNN], optionally with millisecond-precision) instead of datetime strings without time zones (YYYY-MM-DD HH:MM:SS[.MMM]). This means the server will receive the same absolute timestamp the client sent even if the client's time zone and the database server's time zone differ. Previously, if the server used one time zone and the client used another, Date objects would be encoded in the client's time zone and decoded in the server's time zone and create a mismatch.
For instance, if the server used UTC (GMT) and the client used PST (GMT-8), a Date object for "2023-01-01 13:00:00 PST" would be encoded as "2023-01-01 13:00:00" and decoded as "2023-01-01 13:00:00 UTC" (which is 2023-01-01 05:00:00 PST). Now, "2023-01-01 13:00:00 PST" is encoded as "1672606800" and decoded as "2023-01-01 21:00:00 UTC", the same time the client sent.
As far as I can tell, this is almost always the preferred behavior. Should a user need the old behavior, they can manually convert Dates to strings before passing them in as query parameters.
Both unit tests and integration tests pass. Because the client's time zone is now accounted for, the test cases use
Date.UTC()
so they pass even if the computer running the tests is not using UTC.Checklist
Delete items not relevant to your PR: