Re: inverse of "day of year" - Mailing list pgsql-sql

From Martin Marques
Subject Re: inverse of "day of year"
Date
Msg-id 200403221014.40555.martin@bugs.unl.edu.ar
Whole thread Raw
In response to Re: inverse of "day of year"  (Bruno Wolff III <bruno@wolff.to>)
Responses Re: inverse of "day of year"
List pgsql-sql
El Lun 22 Mar 2004 09:50, escribió:
>
> Intervals are stored as two components. One is absolute time difference,
> and the other is in months. '1 year' is equivalent to '12 months'.
> The documentation on how they work in corner cases (when added or
> subtracted from timestamp(tz)) is sparse. It isn't documented whether the
> part in months or the absolute time is added first or what timezone is used
> (for
> timestamptz) when adding the months part.
> The basic idea is that months are added by looking at the timestamp
> as date and time and adding the appropiate number of months to the date
> and then converting back to a timestamp. It isn't documented what happens
> when the day of the month is past the end of the new month, but it looks
> like the last day of new month is used.
> If you convert an interval to an absolute time (such as by extracting the
> epoch), then months are converted to 30 days. Again, I don't think this
> is documented.

Any thoughts on how this could affect date manipulation?

mydb=> select '29/2/2004'::date + ((2005 - date_part('year', now())::int) ||
'years')::interval;     ?column?
---------------------2005-02-28 00:00:00

AFAIKS with other dates this works OK. :-)

-- 10:11:02 up 13 days, 14:42,  4 users,  load average: 0.17, 0.12, 0.16
-----------------------------------------------------------------
Martín Marqués        | select 'mmarques' || '@' || 'unl.edu.ar'
Centro de Telematica  |  DBA, Programador, Administrador            Universidad Nacional                 del Litoral
-----------------------------------------------------------------



pgsql-sql by date:

Previous
From: Erik Thiele
Date:
Subject: Re: special integrity constraints
Next
From: Stephan Szabo
Date:
Subject: Re: special integrity constraints