Re: Macros for time magic values

Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Mon, Mar 14, 2011 at 4:22 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >> On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
> >>> I think it's much clearer with the plain numbers.
>
> >> Yeh. It's not like the values 24, 12 or 60 were going to change.
>
> > I had the same thought. OTOH, even in 9.0 we have constants for
> > BITS_PER_BYTE, DAYS_PER_YEAR (365.25), MONTHS_PER_YEAR, DAYS_PER_MONTH
> > (30, as it turns out), HOURS_PER_DAY, SECS_PER_YEAR (that's a
> > constant?), SECS_PER_DAY, SECS_PER_HOUR, MINS_PER_HOUR, USECS_PER_DAY,
> > USECS_PER_HOUR, USECS_PER_MINUTE, and USECS_PER_SEC. And there's no
> > real reason to use those symbols in only some of the contexts where
> > they are relevant.
>
> Well, those existing symbols are there because Bruce put them in in
> previous iterations of this same sort of patch. And as you note,

Right.

> some of them are pretty darn questionable because the underlying
> number *isn't* as well defined as all that.

The macro does allow us to centralize comments on their imprecision,
e.g.:

/*
* DAYS_PER_MONTH is very imprecise. The more accurate value is
* 365.2425/12 = 30.436875, or '30 days 10:29:06'. Right now we only
* return an integral number of days, but someday perhaps we should
* also return a 'time' value to be used as well. ISO 8601 suggests
* 30 days.
*/
#define DAYS_PER_MONTH 30 /* assumes exactly 30 days per month */

> If Bruce is the only person who finds this to be a readability
> improvement, maybe we should think about backing all of those
> changes out.

Yes, it should be done consistently.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +