"TIMESTAMP and TIME may also be specified as being WITH TIME ZONE, in which case every value has associated with it a time zone displacement. In comparing values of a data type WITH TIME ZONE, the value of the time zone displacement is disregarded." Well what's the point then?
-
-
Replying to @pg_xocolatl
The short version is that the comparison ultimately reflects the difference in the UTC times of the values, ignoring the displacements, which does actually make sense. The long version is ... long
2 replies 0 retweets 2 likes -
Replying to @RhodiumToad @pg_xocolatl
I'd actually like to understand the long version. Timestamps and timezones are the bane of client interface authors!
1 reply 0 retweets 1 like -
Replying to @dave_cramer @pg_xocolatl
The long version of how the spec defines timezones is: a "timezone" is actually just a UTC offset. There are no zone names, DST boundaries, historical zone changes etc. A timestamp with time zone is a UTC timestamp and an offset.
1 reply 0 retweets 0 likes -
Further, the spec says that if a timestamp without time zone is converted to with time zone, the offset used is the session's /current/ UTC offset. If the original timestamp was the other side of a DST boundary: tough, you get the wrong answer.
1 reply 0 retweets 0 likes -
Not to mention that timezones are an optional feature in the first place, so clients can't rely on them. Is it any wonder that "store everything in UTC without time zones" is the standard advice outside the
@PostgreSQL world?1 reply 0 retweets 4 likes -
I'm not sure the advice should be any different in the
@PostgreSQL world2 replies 0 retweets 0 likes
-
-
cool, thanks!
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.