Readyset is a MySQL and Postgres wire-compatible caching layer that sits in front of existing databases to speed up queries and horizontally scale read throughput. Under the hood, ReadySet caches the results of cached select statements and incrementally updates these results over time as the underlying data changes.
Postgres uses the IANA tz database as its source of truth for information about timezones. Specifically, the information is contained within this file, and as far as I can tell, it is compiled into the binary or included as an asset with a Postgres installation. As a result, time zone information varies across Postgres versions, including minor versions.
Readyset similarly relies upon the IANA tz database, albeit in a different way. We use the chrono-tz crate for any timezone-related functionality, which also compiles in information from the tz database (see the tz/ directory here). The problem here is that the versions of the tz database may differ between the version of Postgres Readyset is connected to and the version of the chrono-tz library we are using in that particular Readyset binary. This is problematic because we have the potential to return different results from Postgres for timestamps with timezones that differ across the two versions of the tz database.
Realistically, this will only occur for timezones that have changed recently, which is not likely to be most of them. I ran into this when running proptests for our custom timestamp encoder in readyset-util, but AFAIK, we haven't experienced this in the wild.
Description
Postgres uses the IANA tz database as its source of truth for information about timezones. Specifically, the information is contained within this file, and as far as I can tell, it is compiled into the binary or included as an asset with a Postgres installation. As a result, time zone information varies across Postgres versions, including minor versions.
Readyset similarly relies upon the IANA tz database, albeit in a different way. We use the chrono-tz crate for any timezone-related functionality, which also compiles in information from the tz database (see the tz/ directory here). The problem here is that the versions of the tz database may differ between the version of Postgres Readyset is connected to and the version of the chrono-tz library we are using in that particular Readyset binary. This is problematic because we have the potential to return different results from Postgres for timestamps with timezones that differ across the two versions of the tz database.
Realistically, this will only occur for timezones that have changed recently, which is not likely to be most of them. I ran into this when running proptests for our custom timestamp encoder in
readyset-util, but AFAIK, we haven't experienced this in the wild.Change in user-visible behavior
Yes
Requires documentation change
Yes