Thread: Imprecision of DAYS_PER_MONTH
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
On Thu, Jul 21, 2005 at 09:39:38 -0400, Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > 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? Shouldn't you be using 365.2425/12 (30.436875) for the number of days per month?
Bruno Wolff III <bruno@wolff.to> writes:
> On Thu, Jul 21, 2005 at 09:39:38 -0400,
> Bruce Momjian <pgman@candle.pha.pa.us> wrote:
>> 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?
> Shouldn't you be using 365.2425/12 (30.436875) for the number of days per
> month?
This sort of question is exactly why the entire change was a bad idea.
No one will ever read any of those macros without stopping to look at
the macro definition, which makes them a net readability loss, not gain.
regards, tom lane
Another problem with this patch is the search-and-replace substitution
of "SECS_PER_MINUTE" for "60", when in point of fact there are two
different meanings of "60" in this context. For instance, this
code has no problem:
! int Log_RotationAge = 24 * 60;
but this code looks like it has a units error:
! int Log_RotationAge = HOURS_PER_DAY * SECS_PER_MINUTE;
You need a "MINS_PER_HOUR" or some such if you don't want people
having to look twice at the code.
BTW, if you actually wanted to improve readability, defining a
SECS_PER_YEAR value and replacing the various occurrences of
"36525 * 864" with it would help.
regards, tom lane
Am Donnerstag, den 21.07.2005, 10:48 -0400 schrieb Tom Lane: > Another problem with this patch is the search-and-replace substitution > of "SECS_PER_MINUTE" for "60", when in point of fact there are two > different meanings of "60" in this context. For instance, this > code has no problem: > > ! int Log_RotationAge = 24 * 60; > > but this code looks like it has a units error: > > ! int Log_RotationAge = HOURS_PER_DAY * SECS_PER_MINUTE; > > You need a "MINS_PER_HOUR" or some such if you don't want people > having to look twice at the code. > > BTW, if you actually wanted to improve readability, defining a > SECS_PER_YEAR value and replacing the various occurrences of > "36525 * 864" with it would help. > IIRC the number of seconds in a year is far from a constant. -- Tino Wildenhain <tino@wildenhain.de>
Tino Wildenhain wrote: > Am Donnerstag, den 21.07.2005, 10:48 -0400 schrieb Tom Lane: > > Another problem with this patch is the search-and-replace substitution > > of "SECS_PER_MINUTE" for "60", when in point of fact there are two > > different meanings of "60" in this context. For instance, this > > code has no problem: > > > > ! int Log_RotationAge = 24 * 60; > > > > but this code looks like it has a units error: > > > > ! int Log_RotationAge = HOURS_PER_DAY * SECS_PER_MINUTE; > > > > You need a "MINS_PER_HOUR" or some such if you don't want people > > having to look twice at the code. > > > > BTW, if you actually wanted to improve readability, defining a > > SECS_PER_YEAR value and replacing the various occurrences of > > "36525 * 864" with it would help. > > > IIRC the number of seconds in a year is far from a constant. Yes, I added a comment mentioning that we don't track leap seconds. And this doesn't handle crossing uneven daylight savings time intervals. Comments updated. -- 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
Bruno Wolff III wrote: > On Thu, Jul 21, 2005 at 09:39:38 -0400, > Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > > > 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? > > Shouldn't you be using 365.2425/12 (30.436875) for the number of days per > month? OK, comment updated: /** 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 be usedas well.*/ -- 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
Tom Lane wrote: > Another problem with this patch is the search-and-replace substitution > of "SECS_PER_MINUTE" for "60", when in point of fact there are two > different meanings of "60" in this context. For instance, this > code has no problem: > > ! int Log_RotationAge = 24 * 60; > > but this code looks like it has a units error: > > ! int Log_RotationAge = HOURS_PER_DAY * SECS_PER_MINUTE; > > You need a "MINS_PER_HOUR" or some such if you don't want people > having to look twice at the code. > > BTW, if you actually wanted to improve readability, defining a > SECS_PER_YEAR value and replacing the various occurrences of > "36525 * 864" with it would help. Good idea, both done. -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > BTW, if you actually wanted to improve readability, defining a > > > SECS_PER_YEAR value and replacing the various occurrences of > > > "36525 * 864" with it would help. > > > > > IIRC the number of seconds in a year is far from a constant. > > Yes, I added a comment mentioning that we don't track leap seconds. > And this doesn't handle crossing uneven daylight savings time intervals. It doesn't even represent leap years, never mind leap seconds. -- greg
Greg Stark wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > > > BTW, if you actually wanted to improve readability, defining a > > > > SECS_PER_YEAR value and replacing the various occurrences of > > > > "36525 * 864" with it would help. > > > > > > > IIRC the number of seconds in a year is far from a constant. > > > > Yes, I added a comment mentioning that we don't track leap seconds. > > And this doesn't handle crossing uneven daylight savings time intervals. > > It doesn't even represent leap years, never mind leap seconds. Good, point, mention added. -- 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
In round figures: Since there are 365.2422 days per tropical year, there are 31556926 seconds per year (give or take leap seconds). Ref: http://www.grc.nasa.gov/WWW/K-12/Numbers/Math/Mathematical_Thinking/cale ndar_calculations.htm So 31557600 seems to be off by quite a bit. > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers- > owner@postgresql.org] On Behalf Of Bruce Momjian > Sent: Thursday, July 21, 2005 1:35 PM > To: Greg Stark > Cc: Tino Wildenhain; Tom Lane; PostgreSQL-development; Marc G. Fournier > Subject: Re: [HACKERS] Imprecision of DAYS_PER_MONTH > > Greg Stark wrote: > > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > > > > > BTW, if you actually wanted to improve readability, defining a > > > > > SECS_PER_YEAR value and replacing the various occurrences of > > > > > "36525 * 864" with it would help. > > > > > > > > > IIRC the number of seconds in a year is far from a constant. > > > > > > Yes, I added a comment mentioning that we don't track leap seconds. > > > And this doesn't handle crossing uneven daylight savings time > intervals. > > > > It doesn't even represent leap years, never mind leap seconds. > > Good, point, mention added. > > -- > 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org
Bruno Wolff III wrote: > > Shouldn't you be using 365.2425/12 (30.436875) for the number of days per > month? Well, ISO 8601 prefers "30" to some weird fraction when they define the term "month"; and uses a different term "calendar month" for the exact number of days in a known month. They make a similar distinction between "day" which is defined as "24 hours" and "calendar day" which includes leap seconds, locally inserted & deleted daylight savings time hours, etc. None of this really matters because the SQL standard only chose to import a couple definitions from ISO 8601 which do not include "month" or "day". But regarding the naming; it would be consistent with iso 8601 if people wanted to make a distinction between "months" and "calendar months". http://lists.ebxml.org/archives/ebxml-core/200104/pdf00005.pdf " 3.15 month unit of time of 28, 29, 30 or 31 days NOTE In certain applications a month is regarded as a unit of timeof 30 days. 3.16 month, calendar time-interval resulting from the division of a calendar year in 12 sequential time-intervals, eachwith a specific name and containing a specified number of calendar days 3.6 day unit of time of 24 hours 3.7 day, calendar time-interval starting at [0000] and ending at [2400] (which is equal to the beginning of the nextcalendar day); typically a calendar day has a duration of 24 h [...] NOTE 2 The duration of a calendar day is 24 hours;except if modified by: — the insertion or deletion of leap seconds, by decision of the IERS, or — the insertion ordeletion of other time intervals, as may be prescribed by local authorities to alter local time. "
Dann Corbit wrote: > In round figures: > > Since there are 365.2422 days per tropical year, there are 31556926 > seconds per year (give or take leap seconds). > > Ref: > http://www.grc.nasa.gov/WWW/K-12/Numbers/Math/Mathematical_Thinking/cale > ndar_calculations.htm > > > So 31557600 seems to be off by quite a bit. We can look at improving these numbers, but that is more of a behavior change rather than a code clarity change, and I am not sure we want to get into that now. I will add a TODO to review this for 8.2. --------------------------------------------------------------------------- > > > -----Original Message----- > > From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers- > > owner@postgresql.org] On Behalf Of Bruce Momjian > > Sent: Thursday, July 21, 2005 1:35 PM > > To: Greg Stark > > Cc: Tino Wildenhain; Tom Lane; PostgreSQL-development; Marc G. > Fournier > > Subject: Re: [HACKERS] Imprecision of DAYS_PER_MONTH > > > > Greg Stark wrote: > > > > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > > > > > > > BTW, if you actually wanted to improve readability, defining a > > > > > > SECS_PER_YEAR value and replacing the various occurrences of > > > > > > "36525 * 864" with it would help. > > > > > > > > > > > IIRC the number of seconds in a year is far from a constant. > > > > > > > > Yes, I added a comment mentioning that we don't track leap > seconds. > > > > And this doesn't handle crossing uneven daylight savings time > > intervals. > > > > > > It doesn't even represent leap years, never mind leap seconds. > > > > Good, point, mention added. > > > > -- > > 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 > > > > ---------------------------(end of > broadcast)--------------------------- > > TIP 4: Have you searched our list archives? > > > > http://archives.postgresql.org > -- 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
On Thu, Jul 21, 2005 at 13:47:29 -0700, Dann Corbit <DCorbit@connx.com> wrote: > In round figures: > > Since there are 365.2422 days per tropical year, there are 31556926 > seconds per year (give or take leap seconds). > > Ref: > http://www.grc.nasa.gov/WWW/K-12/Numbers/Math/Mathematical_Thinking/cale > ndar_calculations.htm According to the current calendar (again ignoring leap seconds) there are exactly 365.2425 days per year on average. I think it makes sense to use this number when dealing with calendar years and months.
Bruno Wolff III wrote: > On Thu, Jul 21, 2005 at 13:47:29 -0700, > Dann Corbit <DCorbit@connx.com> wrote: > > In round figures: > > > > Since there are 365.2422 days per tropical year, there are 31556926 > > seconds per year (give or take leap seconds). > > > > Ref: > > http://www.grc.nasa.gov/WWW/K-12/Numbers/Math/Mathematical_Thinking/cale > > ndar_calculations.htm > > According to the current calendar (again ignoring leap seconds) there > are exactly 365.2425 days per year on average. I think it makes sense to use > this number when dealing with calendar years and months. Someone came up with 365.2422. Which is better? -- 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
365.2425 is the exact value computed by the formulas found in the Gregorian calendar (a very good approximation of reality). 365.2422 is the physical reality of how long it actually takes (but there are tiny wobbles in it). http://www.timeanddate.com/date/leapyear.html > -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: Friday, July 22, 2005 12:03 PM > To: Bruno Wolff III > Cc: Dann Corbit; Greg Stark; Tino Wildenhain; Tom Lane; PostgreSQL- > development; Marc G. Fournier > Subject: Re: [HACKERS] Imprecision of DAYS_PER_MONTH > > Bruno Wolff III wrote: > > On Thu, Jul 21, 2005 at 13:47:29 -0700, > > Dann Corbit <DCorbit@connx.com> wrote: > > > In round figures: > > > > > > Since there are 365.2422 days per tropical year, there are 31556926 > > > seconds per year (give or take leap seconds). > > > > > > Ref: > > > http://www.grc.nasa.gov/WWW/K- > 12/Numbers/Math/Mathematical_Thinking/cale > > > ndar_calculations.htm > > > > According to the current calendar (again ignoring leap seconds) there > > are exactly 365.2425 days per year on average. I think it makes sense to > use > > this number when dealing with calendar years and months. > > Someone came up with 365.2422. Which is better? > > -- > 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
Apparently, the Gregorian calendar has been fixed. From this: http://www.physics.uq.edu.au/people/ross/phys2081/time/calendar.htm We have this: "The Gregorian calendar has been modified since (before anything could go wrong) to bring the Gregorian 365.2425 down to 365.2422 by cutting out "leap centuries" that are divisible by 4000 thus giving an accuracy of about one day in 20,000 years" I think either approach would be fine as long as it is documented exactly that the calculation does. > -----Original Message----- > From: Dann Corbit > Sent: Friday, July 22, 2005 12:24 PM > To: 'Bruce Momjian'; Bruno Wolff III > Cc: Greg Stark; Tino Wildenhain; Tom Lane; PostgreSQL-development; Marc G. > Fournier > Subject: RE: [HACKERS] Imprecision of DAYS_PER_MONTH > > 365.2425 is the exact value computed by the formulas found in the > Gregorian calendar (a very good approximation of reality). > > 365.2422 is the physical reality of how long it actually takes (but there > are tiny wobbles in it). > > http://www.timeanddate.com/date/leapyear.html > > > -----Original Message----- > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > Sent: Friday, July 22, 2005 12:03 PM > > To: Bruno Wolff III > > Cc: Dann Corbit; Greg Stark; Tino Wildenhain; Tom Lane; PostgreSQL- > > development; Marc G. Fournier > > Subject: Re: [HACKERS] Imprecision of DAYS_PER_MONTH > > > > Bruno Wolff III wrote: > > > On Thu, Jul 21, 2005 at 13:47:29 -0700, > > > Dann Corbit <DCorbit@connx.com> wrote: > > > > In round figures: > > > > > > > > Since there are 365.2422 days per tropical year, there are 31556926 > > > > seconds per year (give or take leap seconds). > > > > > > > > Ref: > > > > http://www.grc.nasa.gov/WWW/K- > > 12/Numbers/Math/Mathematical_Thinking/cale > > > > ndar_calculations.htm > > > > > > According to the current calendar (again ignoring leap seconds) there > > > are exactly 365.2425 days per year on average. I think it makes sense > to > > use > > > this number when dealing with calendar years and months. > > > > Someone came up with 365.2422. Which is better? > > > > -- > > 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
On 2005-07-22, Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Bruno Wolff III wrote: >> According to the current calendar (again ignoring leap seconds) there >> are exactly 365.2425 days per year on average. I think it makes sense to use >> this number when dealing with calendar years and months. > > Someone came up with 365.2422. Which is better? That's the difference between the tropical year (time between equinoxes) and the calendar year. It will take about 3500 years for that to cause an error of 1 day in the calendar (which has lead to some suggestions that the year 4000 should not be a leap year) but in practice other errors are likely to be more important by then. The calendar year of the Gregorian calendar is 365.2425 days. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services
On Fri, Jul 22, 2005 at 12:27:50 -0700, Dann Corbit <DCorbit@connx.com> wrote: > Apparently, the Gregorian calendar has been fixed. From this: > http://www.physics.uq.edu.au/people/ross/phys2081/time/calendar.htm > > We have this: > "The Gregorian calendar has been modified since (before anything could > go wrong) to bring the Gregorian 365.2425 down to 365.2422 by cutting > out "leap centuries" that are divisible by 4000 thus giving an accuracy > of about one day in 20,000 years" That's interesting. So now we will have a year 4000 problem when there isn't a leap year as was previously scheduled.
Bruno Wolff III wrote: >On Fri, Jul 22, 2005 at 12:27:50 -0700, > Dann Corbit <DCorbit@connx.com> wrote: > > >>Apparently, the Gregorian calendar has been fixed. From this: >>http://www.physics.uq.edu.au/people/ross/phys2081/time/calendar.htm >> >>We have this: >>"The Gregorian calendar has been modified since (before anything could >>go wrong) to bring the Gregorian 365.2425 down to 365.2422 by cutting >>out "leap centuries" that are divisible by 4000 thus giving an accuracy >>of about one day in 20,000 years" >> >> > >That's interesting. So now we will have a year 4000 problem when there >isn't a leap year as was previously scheduled. > > > > remind me about that when we're a bit closer to the date. cheers andrew (who wasted a year of his life on y2k crap).