Re: Alter timestamp without timezone to with timezone rewrites rows
От | Tom Lane |
---|---|
Тема | Re: Alter timestamp without timezone to with timezone rewrites rows |
Дата | |
Msg-id | 1281317.1610551706@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Alter timestamp without timezone to with timezone rewrites rows ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: Alter timestamp without timezone to with timezone rewrites rows
|
Список | pgsql-hackers |
"David G. Johnston" <david.g.johnston@gmail.com> writes: > On Wed, Jan 13, 2021 at 6:59 AM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> > wrote: >> +01 indicates that there's timezone information added to the data, so >> the rows aren't identical. Here's some more SQL run on my laptop which >> shows that > This is indeed true but examples that use the textual representation of the > data don't support the claim. The physical representation of the data is identical, yes, but the *interpretation* is not. In modern PG, timestamptz is int64 microseconds counted from 2000-01-01 00:00:00 UTC, while timestamp is int64 microseconds counted from 2000-01-01 00:00:00 local time (whatever you think local time is). Also, while the display (not storage) of timestamptz accounts for local daylight-savings rules, display of timestamp values does not. Thus, the offset between the stored values of timestamptz and timestamp for the "same" date/time will vary over time. Where I live, there's a five-hour offset right now, but for much of the year it's a four-hour offset. So a non-rewriting conversion would only be possible if local time is identical to UTC; which is true for few enough people that nobody has bothered with attempting the optimization. (From memory, the existing method for deciding whether non-rewriting conversion is possible could not cope with such an environment-dependent rule anyway, so some significant trouble would be involved to figure out how to do it.) regards, tom lane
В списке pgsql-hackers по дате отправления: