Re: pgsql: Add time/date macros for code clarity: #define

Marc G. Fournier wrote:
> On Thu, 21 Jul 2005, Tom Lane wrote:
>
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> Tom Lane wrote:
> >>>> #define DAYS_PER_YEAR   365.25
> >>>> #define MONTHS_PER_YEAR 12
> >>>> #define DAYS_PER_MONTH  30
> >>>> #define HOURS_PER_DAY   24
> >>>
> >>> Considering that only one of these four is actually an accurate
> >>> constant, I have to question the usefulness of this.
> >
> >> Yea, the problem is that these non-absolute constants are littered all
> >> through the code, so it is best to have them at least in one place.  I
> >> will add a comment marking the non-accurate ones more clearly.
> >
> > Unless you comment every single use of the macros, you won't have
> > addressed my point.  No one will ever read "DAYS_PER_YEAR" in the midst
> > of some code and not stop to wonder "hmm, is that 365, or 365.25, or
> > 365.2425"?  And in most places where this might be used, that's not
> > an ignorable issue.  I think it is actually better to write out the
> > literal number, because then you can see right away what is happening.
> >
> > In short, I don't think this is an improvement.
>
> 'k, I have to be missing something here, but other then, what, 5 months of
> the year (not even half), DAYS_PER_MONTH isn't 30 either ... this can't be
> good, especially not for a database ... that's like saying "oh, pi is
> around 3.2" (assuming .05 rounds up to 2 instead of down to 1) ... the
> conversions would only be right 5/12ths of the time ...
>
> Or am I missing something?

No, you are not.  Our using 30 is pretty wacky, but when we need to
convert from months to days/time, that's the only way we can do it.

At least with the macro, we can now know every place we make that
assumption.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073