You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently time fields seem bound to the time library. Working with time zones with time is a PITA so I was saddened to see that cornucopia does not support chrono.
Might implement this myself after Easter. @LouisGariepy@Virgiel Should I implement as a crate feature, e.g. chrono + time where time is default?
The simplest solution for now, would be to use SystemTime for timestamp and timestamptz and let the user match to time or chrono. Latter we could add a feature to make this more ergonomic.
In postgres, timestamps are just microseconds and dates are just number of day. We should use types that match this reality.
I didn't know SystemTime can be used to store historical dates..?
Either way I think the feature approach I mentioned might make more sense though, as postgres-types does it this way. I don't think it makes use of SystemTime at all.
@jacobsvante I didn't add chrono support originally because of the whole unsoundness debacle. I tried to not include crates with serious known vulnerabilities.
This has been fixed in version 4.20, but only if you disable default features and don't enable the oldtime feature. The sound implementation will be the default in a future 0.5.0 release chronotope/chrono#970.
In any case, disregarding the soundness issues, this will probably be actionable via the new codegen architecture #211.
Currently time fields seem bound to the
time
library. Working with time zones withtime
is a PITA so I was saddened to see that cornucopia does not support chrono.Might implement this myself after Easter. @LouisGariepy @Virgiel Should I implement as a crate feature, e.g.
chrono
+time
wheretime
is default?Or maybe #207 would solve this?
The text was updated successfully, but these errors were encountered: