> Yep, you need to do whole shebang of dumping and reloading.
Hmmm.
I think I'll just cheat for a while and add 364 days, hopefully before
the end of NZ daylight savings, the production release of 7.1 will be
out. I really don't want to upgrade twice.
Glen.
> regression=# select '31/12/2000'::date + '365 days'::timespan;
> ?column?
>
> 2001-12-31 00:00:00+13
> (1 row)
>
> This looks promising but I wouldn't call it conclusive, particularly
> since you're probably using a different OS than I am (I'm on HPUX
> 10.20).
> Could one of you try it in 7.1 (beta3 or later)? We've changed some
> details of the way daylight-savings transitions are handled in
> date-to-timestamp conversions, so I think this might be fixed now.
> It's worth checking anyway.
I would prefer not to upgrade right at the moment, as my devel
template1=# select '31/12/2000'::date;
?column?
2000-12-31
(1 row)
template1=# select '31/12/2000'::date + '365 days'::timespan;
?column?
2002-01-01 00:00:00+13<<< Wrong
(1 row)
template1=# select '31/12/2000'::date + '364 days'::time
pressie# select '31/12/2000'::date + '1 year'::timespan;
?column?
-
01/01/2002 00:00:00.00 NZDT
(1 row)
pressie=#
Well I do :-(
I vaguely remember someone else having the same problem and it was
something to do with daylight saving. I don't recall the sol
I am using 7.0.3,
I have a column tstamp defined to be 'date';
With a current value of '31-12-2000',
if I update tstamp=tstamp+'1 year'::timespan
I get '1-1-2002'
Is this what is supposed to occur.
If this isn't the right way to do this, how sho
