-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support BC form of timestamps and dates. #88
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Vasilii Novikov <[email protected]>
Mostly looks good, but I'm getting a test failure on my machine.
Also, I don't understand the change to As far as exporting |
Hm. Thank you I'll try to investigate it.
I mean that we could use this helpers under the hood of pgx here https://github.com/jackc/pgx/blob/master/internal/sanitize/sanitize.go#L51 And for end users time will be encoded implicitly. But OK, I'll make this methods private for now.
In app code with pgx even if we wrap native time with right type we don't get expected result. Because pgx handles I've made simple test:
There will be out of range error from postgres:
because pgx takes But we can avoid the problem if |
Hmm... That simple protocol path is tricky... But at the very least it is surprising for Would it make sense the pgx simple protocol path to handle |
Do you mean a special case like JSONB here? https://github.com/jackc/pgx/blob/master/values.go#L46 Well, I think it is a fair trade-off between potential breaking changes of pgtype date types and supporting rare BC case :) |
Signed-off-by: Vasilii Novikov <[email protected]>
Yes. I'm still getting a strange test failure. It looks like decoding the text format is not handling time zones properly.
|
Signed-off-by: Vasilii Novikov <[email protected]>
Signed-off-by: Vasilii Novikov <[email protected]>
Thank you, I've improved test to catch the problem and fixed it. |
Sorry to keep nitpicking, but this latest change will permanently alter the test database when run, and this also means it requires superuser permissions. I'd prefer to avoid that. I realize the test helper interface does not make it possible / easy to set the connection time zone, but if we were able to do that would that be sufficient for the test case? It might make sense for this test to not use the standard helpers. |
Hello!
I faced some problem with textual representation of dates and timestamps before common era (BC). It is actual only in simple protocol but not in binary.
Firstly if we have a "negative" date in Go or in other words
t.Before(time.Time{}) == true
then textual representation of this date in Postgres must containBC
suffix. Postgres supports dates before common era, but naive string representation oftime.Time
is not fit for this purposes. For example minute before zero time will be in Go0000-12-31 23:59:00
but for Postgres expects0001-12-31 23:59:00 BC
.Secondly I've noticed that even after required improvements were added in
pgtype
it doesn't took an effect. Because date types in pgtype returningtime.Time
"as is" here condorcet@affe9e2#diff-1aef962e6259426c493d2499a5f85405d51a760644acdc53a9e51e0fbbf7b5ccL235 Instead of serialization.For example if we use
pgtype.Timestamp
in application code then appropriate query/exec argument hasdriver.Valuer
type https://github.com/jackc/pgx/blob/master/values.go#L65 but after that we again get nativetime.Time
without proper serialization.So I made explicit encoding in
Value
methods for date types. Is it ok?Lastly I think we can use new helpers for encoding/decoding right into pgx https://github.com/jackc/pgx/blob/38dd42de4bc5ba4b7492b3a07ae4e472fab9517d/values.go#L82 for more user friendly experience with native
time.Time
. What do you think about it?