Tom,
> As far as I can tell, Dennis is planning slavish adherence to the spec,
> which will mean that the datatype is unable to cope effectively with
> daylight-savings issues. So I'm unconvinced that it will be very
> helpful to you for remembering local time in addition to true
> (universal) time.
As somebody who codes calendar apps, I have to say that I have yet to see an
implementation of time zones which is at all useful for this purpose,
including the current implementation. My calendar apps on PostgreSQL 7.4
use "timestamp without time zone" and keep the time zone in a seperate field.
The reason is simple: our current implementation, which does include DST,
does not include any provision for the exceptions to DST -- such as Arizona
-- or for the difference between "1 day" and "24 hours". (Try adding "30
days" to "2004-10-05 10:00 PDT", you'll see what I mean). Nor do I see a
way out of this without raising the complexity, and configurability, level of
timezones significantly.
So if we're going to be broken (at least from the perspective of calendar
applications) we might as well be broken in a spec-compliant way.
--
Josh Berkus
Aglio Database Solutions
San Francisco
