Open
Conversation
Contributor
Author
|
While doing this I toyed with changing certain interfaces in |
Replace all usages of `NaiveDateTime` with `DateTime<Utc>`, which will
mean one less set of conversions we'll need to or from
`janus_messages::Time`.
The scariest thing about this is the implications for the database.
Previously we used `NaiveDateTime` because then we got free
`postgres_types::{FromSql, ToSql}` implementations converting between
`NaiveDateTime` and SQL `TIMESTAMP`. `postgres_types` also provides such
trait implementations so that we can easily go between `DateTime<Utc>`
and SQL `TIMESTAMP WITH TIME ZONE`. It turns out to be quite easy to
change the schema so that all `TIMESTAMP` columns are now `TIMESTAMP
WITH TIME ZONE` and all `TSRANGE`s (timestamp ranges) are now
`TSTZRANGE` (timestamp with timezone range).
Interestingly, a `TIMESTAMP WITH TIME ZONE` is no bigger on disk ([1],
emphasis mine):
> For timestamp with time zone values, an input string that includes an
> explicit time zone will be converted to UTC (Universal Coordinated
> Time) using the appropriate offset for that time zone. If no time zone
> is stated in the input string, then it is assumed to be in the time
> zone indicated by the system's TimeZone parameter, and is converted
> to UTC using the offset for the timezone zone. *In either case, the
> value is stored internally as UTC, and the originally stated or
> assumed time zone is not retained.*
The risky thing here is the handling of timestamps without explicit
timezone information, but by making sure to use `DateTime<Utc>`
everywhere, we can reasonably guarantee that we never handle times in
other time zones (bar a couple of tests where I had to explicitly make
timestamp strings UTC by adding "+00").
[1]: https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-DATETIME-INPUT-TIME-STAMPS
2b69d5d to
2289df2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replace all usages of
NaiveDateTimewithDateTime<Utc>, which will mean one less set of conversions we'll need to or fromjanus_messages::Time.The scariest thing about this is the implications for the database. Previously we used
NaiveDateTimebecause then we got freepostgres_types::{FromSql, ToSql}implementations converting betweenNaiveDateTimeand SQLTIMESTAMP.postgres_typesalso provides such trait implementations so that we can easily go betweenDateTime<Utc>and SQLTIMESTAMP WITH TIME ZONE. It turns out to be quite easy to change the schema so that allTIMESTAMPcolumns are nowTIMESTAMP WITH TIME ZONEand allTSRANGEs (timestamp ranges) are nowTSTZRANGE(timestamp with timezone range).Keep in mind also the majority of these
TIMESTAMP WITH TIME ZONEandTSTZRANGEcolumns will go away as we progress through #4206, becomingBIGINTorINT8RANGEto represent ranges of DAP timestamps.Interestingly, a
TIMESTAMP WITH TIME ZONEis no bigger on disk (1, emphasis mine):The risky thing here is the handling of timestamps without explicit timezone information, but by making sure to use
DateTime<Utc>everywhere, we can reasonably guarantee that we never handle times in other time zones (bar a couple of tests where I had to explicitly make timestamp strings UTC by adding "+00").