I think the issue is that we treat TIMESTAMP WITHOUT TIME ZONE as TIMESTAMP at GMT. We then convert it to a users local timezone within application code.
Scott Mohekey
Systems/Application Specialist – OnTrack – Telogis, Inc.
www.telogis.com www.telogis.co.nz+1 949 625-4115 ext. 207 (USA) +64 3339 2825 x207 (NZ)
Leading Global Platform for Location Based Services
--
This e-mail, and any attachments, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. It is the property of Telogis. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, any attachments thereto, and use of the information contained, is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the original and any copy there of.
On Tue, Sep 15, 2009 at 5:29 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
TIMESTAMP WITHOUT TIME ZONE does not identify a moment in time without
first associating it with a time zone. When Daylight Saving Time
ends, the same TIMESTAMP WITHOUT TIME ZONE values will recur, without
any way to distinguish them from those from the previous hour.
The only use case I have been able to think of, personally, for
TIMESTAMP WITHOUT TIME ZONE is a release date for, say a Harry Potter
book or World of Warcraft expansion set, where as the given moment
arrives in each time zone, stores in that time zone can begin to sell
the given work.
I suspect there's probably one or two other valid uses, but most uses
are just mistakes, waiting to be exposed. For almost every reasonable
use, the right data type is TIMESTAMP WITH TIME ZONE.
-Kevin