On 29 Feb 2024, at 14:51, Tom Lane <t...@sss.pgh.pa.us> wrote: > >>> - time with time zone *does* store the time zone, but this isn’t >>> actually useful and should be avoided (I’m not entirely sure why and the >>> docs only gesture at the problems without stating them, IIRC) > >> No it doesn't store the time zone. Nor do the docs say they do. And >> clearly point out the issue that evaluating a time zone without both date >> and time inputs is basically pointless. > > timetz *does* store a time zone, in the sense of storing a numeric > offset from UTC (i.e., "so many minutes east or west of Greenwich"). > The problem is that in most real-world applications your notion of > "time zone" probably includes annual DST changes, which timetz can't > represent. I don't say the type is completely useless, but its > usefulness is a lot less than you might guess.
The closest I can come to this in the docs is: "The appropriate time zone offset is recorded in the time with time zone value and is output as stored; it is not adjusted to the active time zone.” I expect to be submitting some documentation updates as part of this project, fwiw.
