Tim Landscheidt wrote:
You would have to adjust the result of "(EXTRACT('epoch' FROM B) - EXTRACT('epoch' FROM A)) / EXTRACT('epoch' FROM C)" by a factor of 31/30 (30/28? 28/30?) and then chop off timestamps after B with a "WHERE" clause.
Sam Mason wrote:
I'm not sure where you're going with this. The original idea was generate_series for intervals wasn't it? When you start moving from intervals to specific periods of time (i.e. 1st Jan 1970) then you've lost the reason for working with intervals and you may as well just be working with dates or timestamps. The purpose of intervals, as far as I can tell, is so that you can use things like '1 month' and have it do the "right" thing in our Gregorian calender.
Tim Landscheidt wrote:
JFTR: Hours can of course also be 3601 (or theoretically 3599) seconds long, but not in PostgreSQL :-).
Sam Mason wrote:
Depending on the standard you use, yes. BTW, I believe up to two leap seconds are allowed forward in UTC. I believe there are also plans to drop leap seconds and let time slowly drift out of alignment. I think the idea is that when it starts to matter to people, in a thousand years or so, we'll be an interplanetary species anyway and tying time to earth this way is thought to be silly. It also unnecessarily complicates things that don't really care and not be good enough for things that do care.
And don't forget that day length can vary by at least an hour either way from 24 depending on the date and geographic location. Here in the U.S., tomorrow (November 1, 2009) will be 25 hours long in most, but not all, jurisdictions.
-- Lew -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
