Explain how timestamptz doesn't save tz #379
Conversation
| Note that the time zone is not actually stored. On read, if the session | ||
| time zone setting isn't set to UTC, the offset will be applied to the local | ||
| time component. On write, the offset always 0. |
There was a problem hiding this comment.
I actually think it's slightly misleading to talk about timezone offsets getting applied here because it's always a UTCTime on the Haskell side.
There was a problem hiding this comment.
But anyone that executes select ('2020-01-01' :: timestamptz); will see the offset and wonder how that gets mapped to Haskell. And anyone that reads this Haddock will see 'with time zone' and wonder how that works if it maps to a UTCTime. For example, one could think that the offset would get truncated instead of applied.
Since Orville is also used with data that is written in other places, how do we document the fact that Orville applies the offset when decoding?
There was a problem hiding this comment.
Okay I see where you're coming from now. You'd like to make it clear that Orville is handling the offsets correctly, even though PostgreSQL doesn't store the timezone in the actual timestamp value. We should also say something in the docs for SqlType.timestamp, in that case.
There was a problem hiding this comment.
You're right, I suppose it does make sense to not document expected behaviour. So I'll close this and we can focus on #380.
It confused me a bunch of times that
timestamptzdoesn't actually save the tz. Maybe I will stop getting confused if we document it.