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

On Thu, 21 Jul 2005, Tom Lane wrote:

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664