Kevin Grittner <kgrittn@ymail.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
