pgtype icon indicating copy to clipboard operation
pgtype copied to clipboard

Timestamp with time zone decodes to different locations with different encodings

Open bvisness opened this issue 4 years ago • 1 comments
trafficstars

I'm not sure this is a bug you can or should do anything about, but I figured you should be made aware of it.

The timestamp with time zone (timestamptz) type decodes with different time.Location values depending on the encoding:

  • DecodeText yields a time.Time with location time.UTC
  • DecodeBinary yields a time.Time with location time.Local

You can see this for yourself by running the modified tests found in this commit: https://github.com/bvisness/pgtype/commit/a8594094bc2555692da596a6cf26891ae7de0a88

The reason for this, I think, is that DecodeText uses time.Parse with a format string like "2006-01-02 15:04:05.999999999Z07:00:00". The problem is Z; time.Parse does not recognize Z as a valid timezone specifier and so falls back to parsing as UTC. DecodeBinary simply uses time.Unix, which always produces a local Go time.

As I said, I'm not even really sure if this is a bug since I'm not sure we should depend on a particular time.Location from Postgres, given that the timestamptz from Postgres does not contain any location information. Arguably it could always produce a UTC time, since it's always stored in Postgres as UTC, but as a fully qualified time I'm not sure it even matters.

If anything, the worst part is that there is a discrepancy between the two encodings.

Feel free to close if you don't think it's worth doing anything about!

bvisness avatar May 27 '21 02:05 bvisness

The problem is Z; time.Parse does not recognize Z as a valid timezone specifier and so falls back to parsing as UTC.

It ends up in UTC, but it does handle the +7 offset.

I agree the situation is not ideal, but I'm not sure what would be an improvement. And then there's the problem of not breaking backwards compatibility.

jackc avatar May 29 '21 15:05 jackc