Imprecision of DAYS_PER_MONTH - Mailing list pgsql-hackers

pgman wrote:
> 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.

I have added this comment above the DAYS_PER_MONTH macro:
+ /*+  *    DAYS_PER_MONTH is very imprecise.  The more accurate value is+  *    365.25/12 = 30.4375, or '30 days
10:30:00'. 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.+  */  #define DAYS_PER_MONTH        30              /* assumes exactly 30 days per
month*/
 

Let me add that we could actually do this in many places now because we
are already converting to 'time' in those places.  Is this a TODO?

--  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,
Pennsylvania19073