Re: Macros for time magic values

Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Mon, Mar 14, 2011 at 4:22 AM, Simon Riggs <simon@2ndquadrant.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'.
Rightnow we only *  return an integral number of days, but someday perhaps we should *  also return a 'time' value to
beused 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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +