| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>, Bruce Momjian <bruce(at)momjian(dot)us>, Steve Crawford <scrawford(at)pinpointresearch(dot)com>, rohtodeveloper <rohtodeveloper(at)outlook(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alexey <alexk(at)hintbits(dot)com> |
| Subject: | Re: Why data of timestamptz does not store value of timezone passed to it? |
| Date: | 2014-08-28 22:34:37 |
| Message-ID: | 11839.1409265277@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> But the standard doesn't say anything about storing a time zone
> *name* or *abbreviation* -- it requires that it be stored as UTC
> with the *offset* (in hours and minutes). That makes it pretty
> close to what we have -- it's all about a difference in
> presentation. And as far as I can see it completely dodges the
> kinds of problems you're talking about.
However, the added field creates its own semantic problems.
As an example, is 2014-08-28 18:00:00-04 the same as or different from
2014-08-28 17:00:00-05? If they're different, which one is less?
If they're the same, what's the point of storing the extra field?
And do you really like "equal" values that behave differently,
not only for I/O but for operations such as EXTRACT()?
(I imagine the SQL spec gives a ruling on this issue, which
I'm too lazy to look up; my point is that whatever they did, it
will be the wrong thing for some use-cases.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-08-28 22:45:31 | Re: Multithreaded SIGPIPE race in libpq on Solaris |
| Previous Message | Josh Berkus | 2014-08-28 22:25:49 | Re: Why data of timestamptz does not store value of timezone passed to it? |