...
> Yes, it works!
> But now postgres accepts input and returns output
> in GMT, not local time like before! Is it a feature?
This strategy will not work in general unless you *do* set the time zone
to GMT (if it works at one boundary, say in the fall, then it will fail
at the other boundary in the spring).
It is likely that you set the time zone to one unrecognized by your
system (maybe a typo?), so it reverts to GMT. And with GMT you do not
have to worry about daylight savings time or offsets between dates and
times of day in different time zones.
But that is a workaround for the fundamental problem that you want to
solve, which is to get exact *qualitative* date calculations around DST
boundaries.
In the long run, we should probably implement some exact date/interval
arithmetic instead of relying on timestamp types in the intermediate
calculations.
In the meantime you can set time zones or, if you have a fixed query
with date in and date out, and intervals which are multiples of a day,
then you can simply add 12 hours in the query to get the rounding you
expect:
cast((date '2001-10-28' + interval '1 day' + interval '12 hours') as
date)
- Thomas
