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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: Add time/date macros for code clarity: #define DAYS_PER_YEAR
Дата
Msg-id 15366.1121921557@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql: Add time/date macros for code clarity: #define  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: pgsql: Add time/date macros for code clarity: #define  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: pgsql: Add time/date macros for code clarity:  ("Marc G. Fournier" <scrappy@postgresql.org>)
Список pgsql-committers
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.

            regards, tom lane

В списке pgsql-committers по дате отправления:

Предыдущее
От: momjian@svr1.postgresql.org (Bruce Momjian)
Дата:
Сообщение: pgsql: Add comment marking non-exact time conversion macros.
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pgsql: Add time/date macros for code clarity: #define