Accurate Age Calculation
- Thread starter Negger
- Start date
RainLover
VIP From a land downunder
- Local time
- Tomorrow, 05:30
- Joined
- Jan 5, 2009
- Messages
- 5,041
ChrisO
I sometimes wonder at people's lack of understanding about Dates. I think that you and I are the only two who understand them.
What would happen if we told them about negative Days.
Yes I know. You were the one who enlightened me.
I sometimes wonder at people's lack of understanding about Dates. I think that you and I are the only two who understand them.
What would happen if we told them about negative Days.
Yes I know. You were the one who enlightened me.
Greetings:
I just realized that I had a typo in the formula for the calculation of the number of days in a year I posted earlier, for which I apologize. The correct formula has a plus sign not a minus sign for the adjustment due to the 4 year and the 400 year leap year rules:
((400*365) + (400/4)-3))/400 = (146,000 + 97)/ 400 = 146,097/400 = 365.2425. A year is slightly longer than 365 days, not shorter. This is as accurate as our calendar permits, which is not perfect, as I described before.
The age calculation I posted earlier [AccurateAgeR:Round((Date()-[DOB])/365.2425,1)] would need 5 decimal places to render the age in years as less than one year for Brian's example; that is, for a person born March 1, 2011, whose age was calculated on 2/29/2012. But it would never show 0 years and 11 months because months are not included in the expression. With 5 decimal places, that person's age would be rendered as 0.99993 years old.
The Gregorian calendar has no 4,000 year rule, but needs one to be more accurate. The first year of a century skips a leap year, except once every 400 years, in years that are evenly divisible by 400. So 1900, the first year of the 20th century, skipped a leap year, but 2000 had one. The next time a leap year will be skipped will be 2300, the first year of the 24th century. This adjustment overcompensates for the true length of the year in the opposite direction that leap years do. To be more accurate still, the first year of the 40th century, the year 3900, would have to have a leap year. So our calendar already makes us off about 12 hours in 2000 years or about 8.64 minutes per year.
My point earlier was that a calendar is a social and political event, not a reality in the world. Our Gregorian calendar was first adopted by a Papal decision in 1582. It is not perfect, and cannot be expected to be. It is a social measurement tool located in society, not in a scientific laboratory. We know that every year is the same length because the earth does not speed up and slow down so that some years have 365 days and some have 366. Leap year is a measurement artifact, not a reality in the universe. Assuming that human constructions like time and dates are inherent in the universe, has been called reification.
The reason the person in Brian’s example, after 365 days, is shown as less than a year old, with five decimal places is that a year is slightly more than 365 days: It is 365 days and 5.88 hours, or 365.2425 days (notwithstanding the lack of a 4,000 year rule). It is not because March 1 has not arrived yet. That is why the expression does not include months and days. A calculation including years, months, and days, reproduces the error inherent in the calendar. Our calendar, falsely, makes years appear to be different lengths. It would be interesting to see which calculation would hold up better in court.
Still, I readily acknowledge that the expression I posted earlier does not solve the issue of making mathematical date calculations conform to our habits of speech in society, which is what I set out to do. In mathematics, you cannot avoid rounding up and rounding down at the same time, and you cannot avoid the inherent measurement error in the calendar.
In order to be more accurate still, you would have to add the time of day and precise place as well, as you are well aware. Where is the Star Date/Time field when we need it?; that is, some point of reference, relevant to us all, more inclusive than "when," as we say, the sun comes up.
I want to say that I appreciate Brian's points, both of them. I certainly did not intend to appear pontificating, or beside the point. But the entire point of this thread is to raise the other scientific and philosophical issues, which lie behind dates and time. My point was the same as everyone’s: time is a human creation just like mathematics.
There is no such thing as perfect measurement. In the case of age from DOB, this is so primarily because our calendar is not perfect. Using our calendar, we already know that we are off by about 12 hrs over the last 2,000 years.
If we look at the other factors discussed in this thread, like longitude and latitude, we can see that they mostly cancel each other out. A person born at 10PM in San Francisco, would be shown as a day older than a person born at 1 AM in New York (other things equal), even though they were born at precisely the same moment. (Well, not precisely the same moment, perhaps, because NY and SF do not have precisely the same relative position within a time zone. Longitude is relevant in terms of their relative position within a time zone; another obfuscating human construction.) Still, a day later, both persons are equally one day older as long as both ages are calculated from a standardized reference point. If a person's age is calculated simultaneously in different places, where today's date is not the same, there would of, course, be a discrepancy. This is no different than if you went into your computer and reset today's date. The point of reference has to be standardized. Many people probably assume that the point of reference is already standardized since their computer tells them the date: another example of reification.
The same is true for latitude. The boundaries of time zones wander, primarily due to regional economics. The time zone selected for the poles is nearly entirely arbitrary except for economic reasons, such as plane schedules to and from Antarctica and Australia. When the time zone boundary wanders either east or west, so does the relative position within a time zone. As a further illustration of how time is a social and political construction, the exact specification for the location of time zones and the dividing lines between zones in the US is set forth in the Code of Federal Regulations at 49 CFR 71. Time is a legal construct.
Still, given a standardized starting date, age from DOB is otherwise immune from these vagaries. A person's age must be off slightly because of our calendar. A year is not precisely 365.2425 days long.
We could improve the accuracy of age calculations by requiring that birth certificates include the GPS coordinates of the place of birth. And we could reconstruct this by having a look up table showing the GPS coordinates for zip codes or other locations. This would permit the calculation of the Greenwich-mean-date and time, as well as local date and local time, and adjust for the relative position within a time zone. "When" is complex but not insoluble.
I worked for Congress for many years. I studied risk assessment quite a bit; from drugs, to medical devices, to nuclear reactors. One of the questions always asked there was, "How safe is safe enough?" It is apropos here to ask: How accurate is accurate enough? The only time in 40 years of public policy research that I ever saw the accurate age issue arise as a real problem, was in a situation where child services could not be delivered to persons 18 years of age or older, and elderly services to persons less than age 65, according to law (of course, the law does not specify how age shall be calculated). Of course, most of the clients who needed the child services were already age 17. Rounding up was the issue there since about 40 percent of the clients were between 17.5 and 18. All clients between age 17.49 and 17.99... appeared as ineligible for the services rendered due to rounding up. Including a few decimal places helped a lot.
In this case, though, there is another better method, which is to add 18 (or 65) years to DOB and derive a last (or first) eligibility date. In any instance where the DOB plus 18 years (or other amount) is off by say less than two days from the eligibility date, the other factors discussed in this thread could be researched. Mainly, that degree of accuracy is something that would only come up in individual cases or as a legal issue. “Was this person really under 18 on the date services began?“ “Is 17.99993 really under 18?”
As far as a general, accurate age calculation goes, it appears to me that the expression I included earlier is about the most "accurate" we can get. That is not to say that it is the best in all situations. Reports want to include the age of this person in years, succinctly. We can compensate, but we cannot avoid rounding up and down at the same time, and we cannot avoid the measurement error inherent in the calendar. That was my earlier point.
David
I just realized that I had a typo in the formula for the calculation of the number of days in a year I posted earlier, for which I apologize. The correct formula has a plus sign not a minus sign for the adjustment due to the 4 year and the 400 year leap year rules:
((400*365) + (400/4)-3))/400 = (146,000 + 97)/ 400 = 146,097/400 = 365.2425. A year is slightly longer than 365 days, not shorter. This is as accurate as our calendar permits, which is not perfect, as I described before.
The age calculation I posted earlier [AccurateAgeR:Round((Date()-[DOB])/365.2425,1)] would need 5 decimal places to render the age in years as less than one year for Brian's example; that is, for a person born March 1, 2011, whose age was calculated on 2/29/2012. But it would never show 0 years and 11 months because months are not included in the expression. With 5 decimal places, that person's age would be rendered as 0.99993 years old.
The Gregorian calendar has no 4,000 year rule, but needs one to be more accurate. The first year of a century skips a leap year, except once every 400 years, in years that are evenly divisible by 400. So 1900, the first year of the 20th century, skipped a leap year, but 2000 had one. The next time a leap year will be skipped will be 2300, the first year of the 24th century. This adjustment overcompensates for the true length of the year in the opposite direction that leap years do. To be more accurate still, the first year of the 40th century, the year 3900, would have to have a leap year. So our calendar already makes us off about 12 hours in 2000 years or about 8.64 minutes per year.
My point earlier was that a calendar is a social and political event, not a reality in the world. Our Gregorian calendar was first adopted by a Papal decision in 1582. It is not perfect, and cannot be expected to be. It is a social measurement tool located in society, not in a scientific laboratory. We know that every year is the same length because the earth does not speed up and slow down so that some years have 365 days and some have 366. Leap year is a measurement artifact, not a reality in the universe. Assuming that human constructions like time and dates are inherent in the universe, has been called reification.
The reason the person in Brian’s example, after 365 days, is shown as less than a year old, with five decimal places is that a year is slightly more than 365 days: It is 365 days and 5.88 hours, or 365.2425 days (notwithstanding the lack of a 4,000 year rule). It is not because March 1 has not arrived yet. That is why the expression does not include months and days. A calculation including years, months, and days, reproduces the error inherent in the calendar. Our calendar, falsely, makes years appear to be different lengths. It would be interesting to see which calculation would hold up better in court.
Still, I readily acknowledge that the expression I posted earlier does not solve the issue of making mathematical date calculations conform to our habits of speech in society, which is what I set out to do. In mathematics, you cannot avoid rounding up and rounding down at the same time, and you cannot avoid the inherent measurement error in the calendar.
In order to be more accurate still, you would have to add the time of day and precise place as well, as you are well aware. Where is the Star Date/Time field when we need it?; that is, some point of reference, relevant to us all, more inclusive than "when," as we say, the sun comes up.
I want to say that I appreciate Brian's points, both of them. I certainly did not intend to appear pontificating, or beside the point. But the entire point of this thread is to raise the other scientific and philosophical issues, which lie behind dates and time. My point was the same as everyone’s: time is a human creation just like mathematics.
There is no such thing as perfect measurement. In the case of age from DOB, this is so primarily because our calendar is not perfect. Using our calendar, we already know that we are off by about 12 hrs over the last 2,000 years.
If we look at the other factors discussed in this thread, like longitude and latitude, we can see that they mostly cancel each other out. A person born at 10PM in San Francisco, would be shown as a day older than a person born at 1 AM in New York (other things equal), even though they were born at precisely the same moment. (Well, not precisely the same moment, perhaps, because NY and SF do not have precisely the same relative position within a time zone. Longitude is relevant in terms of their relative position within a time zone; another obfuscating human construction.) Still, a day later, both persons are equally one day older as long as both ages are calculated from a standardized reference point. If a person's age is calculated simultaneously in different places, where today's date is not the same, there would of, course, be a discrepancy. This is no different than if you went into your computer and reset today's date. The point of reference has to be standardized. Many people probably assume that the point of reference is already standardized since their computer tells them the date: another example of reification.
The same is true for latitude. The boundaries of time zones wander, primarily due to regional economics. The time zone selected for the poles is nearly entirely arbitrary except for economic reasons, such as plane schedules to and from Antarctica and Australia. When the time zone boundary wanders either east or west, so does the relative position within a time zone. As a further illustration of how time is a social and political construction, the exact specification for the location of time zones and the dividing lines between zones in the US is set forth in the Code of Federal Regulations at 49 CFR 71. Time is a legal construct.
Still, given a standardized starting date, age from DOB is otherwise immune from these vagaries. A person's age must be off slightly because of our calendar. A year is not precisely 365.2425 days long.
We could improve the accuracy of age calculations by requiring that birth certificates include the GPS coordinates of the place of birth. And we could reconstruct this by having a look up table showing the GPS coordinates for zip codes or other locations. This would permit the calculation of the Greenwich-mean-date and time, as well as local date and local time, and adjust for the relative position within a time zone. "When" is complex but not insoluble.
I worked for Congress for many years. I studied risk assessment quite a bit; from drugs, to medical devices, to nuclear reactors. One of the questions always asked there was, "How safe is safe enough?" It is apropos here to ask: How accurate is accurate enough? The only time in 40 years of public policy research that I ever saw the accurate age issue arise as a real problem, was in a situation where child services could not be delivered to persons 18 years of age or older, and elderly services to persons less than age 65, according to law (of course, the law does not specify how age shall be calculated). Of course, most of the clients who needed the child services were already age 17. Rounding up was the issue there since about 40 percent of the clients were between 17.5 and 18. All clients between age 17.49 and 17.99... appeared as ineligible for the services rendered due to rounding up. Including a few decimal places helped a lot.
In this case, though, there is another better method, which is to add 18 (or 65) years to DOB and derive a last (or first) eligibility date. In any instance where the DOB plus 18 years (or other amount) is off by say less than two days from the eligibility date, the other factors discussed in this thread could be researched. Mainly, that degree of accuracy is something that would only come up in individual cases or as a legal issue. “Was this person really under 18 on the date services began?“ “Is 17.99993 really under 18?”
As far as a general, accurate age calculation goes, it appears to me that the expression I included earlier is about the most "accurate" we can get. That is not to say that it is the best in all situations. Reports want to include the age of this person in years, succinctly. We can compensate, but we cannot avoid rounding up and down at the same time, and we cannot avoid the measurement error inherent in the calendar. That was my earlier point.
David
RainLover
VIP From a land downunder
- Local time
- Tomorrow, 05:30
- Joined
- Jan 5, 2009
- Messages
- 5,041
David
Have you looked at my post where I include a Sample Database.
Mine will calculate accurately the Age in either Years, or Years/Months/Days.
As I said previously the OP wanted age to include Years,Months, and Days.
If you can't do that then your Post, although very interesting is of little Value.
Have you looked at my post where I include a Sample Database.
Mine will calculate accurately the Age in either Years, or Years/Months/Days.
As I said previously the OP wanted age to include Years,Months, and Days.
If you can't do that then your Post, although very interesting is of little Value.
ChrisO
Registered User.
- Local time
- Tomorrow, 05:30
- Joined
- Apr 30, 2003
- Messages
- 3,202
As a demonstration of the apparently screwy nature of age calculation we only need to look at the birthday list on the home page. At time of writing, in Brisbane we can see three birthdays listed but in New York there are only two listed.
For all intents and purposes, all the clocks concerned are just as accurate as each other.
The same calculation method is being applied to all users.
The people concerned have a definite age; they therefore have a birthday at a definite time. The positional data (position in time {GMT offset +/- daylight saving}) as used in the users CP, leads to different results.
The reason for the different results is that positional data is being applied to the logged in users time, their computer, their GMT offset. But no allowance is being made for position in time for date of birth. There is no way for a person to enter a GMT offset correction for their date of birth.
This means that the method of calculation, as used by the server, gets screwed.
The method of calculation, for a logged in user, allows only for the data it has. That data contains positional data for the local computer’s time, server +/- GMT, but it does not have server +/- GMT for the date of birth. The method of calculation of age, for logged in users, produces different results because of the lack of information on one side of the calculation.
For everyone to get the same result we all need to log out. That removes the positional data from the local computer’s time, GMT offset, and therefore we are all using server time. Since we have no positional data for date of birth and we are all using the same server time the positions cancel and we all get the same result.
If we are all logged out, the fact that we all get the same result does not mean we all get the correct result. The server still has a position, +/- GMT offset, but the date of birth does not. It simply means that, if there is an error, we all share the same error.
This ‘sharing of error’ also happens in other measurement fields. It might be referred to as agreement on error or agreement on accuracy or whatever it may be called.
An example would the custody transfer of goods between parties. This seems to breakdown to two things (1) absolute accuracy of measurement is not obtainable and (2) the parties must agree on the limitations of accuracy.
A specific example would be the custody transfer of natural gas. Volumetric, mass or calorific value transfer; it’s up to the parties to agree on the method and accuracy of measurement.
Another example is the custody transfer of liquids in a pipe. More than one liquid can flow in a pipe at any given time. Sometimes those liquids will be separated by a pig, sometimes not. The interface between flowing liquids is not absolute, blending can take place. But an agreement can be made governing the accuracy of the plug flow without a pig.
Another example which is perhaps a little closer to home. We pay our electricity bill based on meter readings but who said the reading or meter was accurate? We pay our bill on an agreement that the reading was accurate.
Because of the limit of positional data, the age calculation is the same. It can not be calculated accurately, it must be agreed to be correct between the parties concerned.
Rain supplied an answer and Negger accepted that answer as correct within the confines of Negger’s need. It’s a done and dusted deal; the parties have agreed.
If someone can supply a better solution, given the lack of information supplied, then I would like to see it. Perhaps the people who wrote the server software would also like to see it.
Chris.
For all intents and purposes, all the clocks concerned are just as accurate as each other.
The same calculation method is being applied to all users.
The people concerned have a definite age; they therefore have a birthday at a definite time. The positional data (position in time {GMT offset +/- daylight saving}) as used in the users CP, leads to different results.
The reason for the different results is that positional data is being applied to the logged in users time, their computer, their GMT offset. But no allowance is being made for position in time for date of birth. There is no way for a person to enter a GMT offset correction for their date of birth.
This means that the method of calculation, as used by the server, gets screwed.
The method of calculation, for a logged in user, allows only for the data it has. That data contains positional data for the local computer’s time, server +/- GMT, but it does not have server +/- GMT for the date of birth. The method of calculation of age, for logged in users, produces different results because of the lack of information on one side of the calculation.
For everyone to get the same result we all need to log out. That removes the positional data from the local computer’s time, GMT offset, and therefore we are all using server time. Since we have no positional data for date of birth and we are all using the same server time the positions cancel and we all get the same result.
If we are all logged out, the fact that we all get the same result does not mean we all get the correct result. The server still has a position, +/- GMT offset, but the date of birth does not. It simply means that, if there is an error, we all share the same error.
This ‘sharing of error’ also happens in other measurement fields. It might be referred to as agreement on error or agreement on accuracy or whatever it may be called.
An example would the custody transfer of goods between parties. This seems to breakdown to two things (1) absolute accuracy of measurement is not obtainable and (2) the parties must agree on the limitations of accuracy.
A specific example would be the custody transfer of natural gas. Volumetric, mass or calorific value transfer; it’s up to the parties to agree on the method and accuracy of measurement.
Another example is the custody transfer of liquids in a pipe. More than one liquid can flow in a pipe at any given time. Sometimes those liquids will be separated by a pig, sometimes not. The interface between flowing liquids is not absolute, blending can take place. But an agreement can be made governing the accuracy of the plug flow without a pig.
Another example which is perhaps a little closer to home. We pay our electricity bill based on meter readings but who said the reading or meter was accurate? We pay our bill on an agreement that the reading was accurate.
Because of the limit of positional data, the age calculation is the same. It can not be calculated accurately, it must be agreed to be correct between the parties concerned.
Rain supplied an answer and Negger accepted that answer as correct within the confines of Negger’s need. It’s a done and dusted deal; the parties have agreed.
If someone can supply a better solution, given the lack of information supplied, then I would like to see it. Perhaps the people who wrote the server software would also like to see it.
Chris.
Last edited:
RainLover
VIP From a land downunder
- Local time
- Tomorrow, 05:30
- Joined
- Jan 5, 2009
- Messages
- 5,041
David you should test before posting. At least check that the Syntax is correct by placing it in the Editor or in a Query.
Count the Number of Brackets.
I Count 3 Left and 4 Right.
Last edited:
Greetings:
Somehow my comments are not always being received in the congenial and even playful manner in which they were conveyed. There is a serious element here to be sure, but let us not take ourselves too seriously.
My point has been that human, societal customs of speech and making up calendars are not entirely "scientific;" they are rooted in traditions and habits, hundreds and thousands of years old, and they are not very “accurate.” In that same spirit, whether a parenthesis is left out of a purely illustrative formula is not worthy of note, when the accurate result is obvious. To make a note of it almost sounds like someone has their knickers in a twist over nothing.
Still, when it comes to using a calendar-based programming function, the error included in our calendar must be reproduced. There is obvious error if we say that a person is a year older after 365 days in some years, but that in other years the same person is not a year older until 366 days have elapsed, when we know that all years are the same length; changes in a year's duration over eons of time notwithstanding. By the rules of logic (another human construction) any age calculated using this approach must contain error.
I found a website, which explains this error better than I did originally. It is quoted at the end of this post. It shows that even more accuracy is possible in the number of days per year than I used originally. Obviously, the error using calendar-based formulas may not be readily apparent, when done extremely well as in Rainwater's rendition, unless a significant number of decimal places are called for. There is nothing wrong with Rainwater's approach, and it has never been my intent to imply that there was. I am trying to add to, not to contradict. Still, the conversation is bigger than that.
So, what’s in a year, and what do we mean by accurate? That has been my point all along.
What I set out to do initially was to create a calculated field expression using “((Date()-[DOB])/days in a year,” using an accurate number of days per year, which would avoid the error inherent in our calendar and yet honor our societal habits of speech by avoiding rounding error, or honoring that rounding error where we do in speech.
Using the round function, as I did initially, was not quite the way to do that. But the fix function appears to work.
That expression is:
AccurateAgeFix:Fix((Date()-[DOB])/365.2425)
The fix function trims the result to zero decimal places without any rounding. I was aware of the fix function some time ago, but (as in the examples I saw) if the expression uses the the wrong number of days per year, it still returns incorrect ages. With a more correct number of days per year it appears to work well.
The attached results are from Rainwater’s query with all three of my posted calculations added in subsequent fields. For the last row of output, I changed the current date on my computer to 2/29/2012, so as to conform to Brian’s earlier example. Identical results are returned with no decimal places. After two years for that person, on March 1, in which the second year was not a leap year, that example would have 731/365.2425 = 2.0014 years old.
Is there any difference between the two expressions with no decimal places? I do not think so, since they are based on the same calendar. But that was not the point of asking about age accuracy in the first place. At the very least, the above expression demonstrates that a (Date()-[DOB]) expression can return identical results with no decimal places as a DateDiff expression, and perhaps better with N decimal places, depending on the accuracy of the estimate of the number of days in a year.
The decimal places would not be relevant, of course, unless something significantly more accurate than years with no decimal places was called for, such as corrections for departures from Greenwich mean time (GMT) in "relevant" date/time and DOB/time. If the question of accurate age came down to hours and minutes, as everyone discussed in earlier posts, then more accurate decimal places would be required in the age estimate.
I do not think they would be available with the DateDiff function, at least not as presented. If decimal places were or could be added, then the DateDiff function would begin to reveal its inherent error as decimal places were added. With 12 decimal places as the default, the (Date()-[DOB]) function would support any correction for departures from GMT, using look-up tables or any other relevant technology. Both "relevant" date and DOB would be easily adjusted for departures from GMT. That is, you would standardize relevant date and DOB to GMT, to have a common point of reference. If you knew the time of day for DOB and relevant date, that could easily be standardized to GMT too.
I do not see that there is any reason to be short or mocking with anyone who participates with a true heart and serious intent, however wrong they may be in some particulars, some of the time. We are here to help each other, not to ridicule each other, or to pretend that we are somehow better than each other. If I have still made an error, it is an honest error, and there is no reason I should be made to feel less for it. I am certainly not attempting to disparage anyone for their significant and valuable efforts.
Below is the text and citation regarding the accurate length of a year that I mentioned above:
“A year is the time it takes for the Earth to complete one revolution around the sun. Specifically, this period is 365.242199 days (365 days, 5 hours, 48 minutes, 46 seconds). [There is even some discrepancy here because it depends on whether the equatorial year or the sidereal year is considered. “There is no such thing as perfect measurement.”] The fact that a year is not comprised of a whole number of days has posed challenges to calendar-makers throughout the millennia. For instance, the ancient Egyptians, Romans, and Greeks used calendars with 365 days. This calendar, however, was off by an entire day approximately every four years.
A big improvement was made with the Julian calendar, crafted by Julius Caesar (100-44 B.C.) in 46 B.C. The Julian calendar, which was 365.25 days long, inserted an extra day, or "leap day," every fourth year. Even with that adjustment, the Julian calendar was off by 11 minutes and 14 seconds per year. By the mid-1500s that error had accumulated so that the Julian calendar was 10 days ahead of the Earth's natural [“accurate”] cycle.
The next, and current, version of the calendar is called the Gregorian calendar. It is named after Pope Gregory XII (1502-1585), who in 1582 adjusted the length of the calendar to 365.2425 days per year [by adding the 400 year rule described (however flawed by a missing a parenthesis) earlier] (just .00301 days, or 26 seconds, per year different from the actual ["accurate'] length).”
Sources:
Engelbert, Phillis. Astronomy and Space: From the Big Bang to the Big Crunch, vol. 31, pp. 79-81
Pasachoff, Jay M. Contemporary Astronomy, p. 88.
"It is estimated that, by the year 4000, the vernal equinox will fall back by one day in the Gregorian calendar, not because of this difference [the slight error in the Gregorian calendar], but because of the [natural] slowing down of the Earth's rotation and the associated lengthening of the sidereal day."
In other words, a change in the underlying, independent reality of the universe will eventually overtake the accuracy of our calendars and our mathematical calculations. Where is the StarDate/Time field when we need it?
Ciao,
David
Somehow my comments are not always being received in the congenial and even playful manner in which they were conveyed. There is a serious element here to be sure, but let us not take ourselves too seriously.
My point has been that human, societal customs of speech and making up calendars are not entirely "scientific;" they are rooted in traditions and habits, hundreds and thousands of years old, and they are not very “accurate.” In that same spirit, whether a parenthesis is left out of a purely illustrative formula is not worthy of note, when the accurate result is obvious. To make a note of it almost sounds like someone has their knickers in a twist over nothing.
Still, when it comes to using a calendar-based programming function, the error included in our calendar must be reproduced. There is obvious error if we say that a person is a year older after 365 days in some years, but that in other years the same person is not a year older until 366 days have elapsed, when we know that all years are the same length; changes in a year's duration over eons of time notwithstanding. By the rules of logic (another human construction) any age calculated using this approach must contain error.
I found a website, which explains this error better than I did originally. It is quoted at the end of this post. It shows that even more accuracy is possible in the number of days per year than I used originally. Obviously, the error using calendar-based formulas may not be readily apparent, when done extremely well as in Rainwater's rendition, unless a significant number of decimal places are called for. There is nothing wrong with Rainwater's approach, and it has never been my intent to imply that there was. I am trying to add to, not to contradict. Still, the conversation is bigger than that.
So, what’s in a year, and what do we mean by accurate? That has been my point all along.
What I set out to do initially was to create a calculated field expression using “((Date()-[DOB])/days in a year,” using an accurate number of days per year, which would avoid the error inherent in our calendar and yet honor our societal habits of speech by avoiding rounding error, or honoring that rounding error where we do in speech.
Using the round function, as I did initially, was not quite the way to do that. But the fix function appears to work.
That expression is:
AccurateAgeFix:Fix((Date()-[DOB])/365.2425)
The fix function trims the result to zero decimal places without any rounding. I was aware of the fix function some time ago, but (as in the examples I saw) if the expression uses the the wrong number of days per year, it still returns incorrect ages. With a more correct number of days per year it appears to work well.
The attached results are from Rainwater’s query with all three of my posted calculations added in subsequent fields. For the last row of output, I changed the current date on my computer to 2/29/2012, so as to conform to Brian’s earlier example. Identical results are returned with no decimal places. After two years for that person, on March 1, in which the second year was not a leap year, that example would have 731/365.2425 = 2.0014 years old.
Is there any difference between the two expressions with no decimal places? I do not think so, since they are based on the same calendar. But that was not the point of asking about age accuracy in the first place. At the very least, the above expression demonstrates that a (Date()-[DOB]) expression can return identical results with no decimal places as a DateDiff expression, and perhaps better with N decimal places, depending on the accuracy of the estimate of the number of days in a year.
The decimal places would not be relevant, of course, unless something significantly more accurate than years with no decimal places was called for, such as corrections for departures from Greenwich mean time (GMT) in "relevant" date/time and DOB/time. If the question of accurate age came down to hours and minutes, as everyone discussed in earlier posts, then more accurate decimal places would be required in the age estimate.
I do not think they would be available with the DateDiff function, at least not as presented. If decimal places were or could be added, then the DateDiff function would begin to reveal its inherent error as decimal places were added. With 12 decimal places as the default, the (Date()-[DOB]) function would support any correction for departures from GMT, using look-up tables or any other relevant technology. Both "relevant" date and DOB would be easily adjusted for departures from GMT. That is, you would standardize relevant date and DOB to GMT, to have a common point of reference. If you knew the time of day for DOB and relevant date, that could easily be standardized to GMT too.
I do not see that there is any reason to be short or mocking with anyone who participates with a true heart and serious intent, however wrong they may be in some particulars, some of the time. We are here to help each other, not to ridicule each other, or to pretend that we are somehow better than each other. If I have still made an error, it is an honest error, and there is no reason I should be made to feel less for it. I am certainly not attempting to disparage anyone for their significant and valuable efforts.
Below is the text and citation regarding the accurate length of a year that I mentioned above:
“A year is the time it takes for the Earth to complete one revolution around the sun. Specifically, this period is 365.242199 days (365 days, 5 hours, 48 minutes, 46 seconds). [There is even some discrepancy here because it depends on whether the equatorial year or the sidereal year is considered. “There is no such thing as perfect measurement.”] The fact that a year is not comprised of a whole number of days has posed challenges to calendar-makers throughout the millennia. For instance, the ancient Egyptians, Romans, and Greeks used calendars with 365 days. This calendar, however, was off by an entire day approximately every four years.
A big improvement was made with the Julian calendar, crafted by Julius Caesar (100-44 B.C.) in 46 B.C. The Julian calendar, which was 365.25 days long, inserted an extra day, or "leap day," every fourth year. Even with that adjustment, the Julian calendar was off by 11 minutes and 14 seconds per year. By the mid-1500s that error had accumulated so that the Julian calendar was 10 days ahead of the Earth's natural [“accurate”] cycle.
The next, and current, version of the calendar is called the Gregorian calendar. It is named after Pope Gregory XII (1502-1585), who in 1582 adjusted the length of the calendar to 365.2425 days per year [by adding the 400 year rule described (however flawed by a missing a parenthesis) earlier] (just .00301 days, or 26 seconds, per year different from the actual ["accurate'] length).”
Sources:
Engelbert, Phillis. Astronomy and Space: From the Big Bang to the Big Crunch, vol. 31, pp. 79-81
Pasachoff, Jay M. Contemporary Astronomy, p. 88.
"It is estimated that, by the year 4000, the vernal equinox will fall back by one day in the Gregorian calendar, not because of this difference [the slight error in the Gregorian calendar], but because of the [natural] slowing down of the Earth's rotation and the associated lengthening of the sidereal day."
In other words, a change in the underlying, independent reality of the universe will eventually overtake the accuracy of our calendars and our mathematical calculations. Where is the StarDate/Time field when we need it?
Ciao,
David
Greetings:
Thanks for your kind response. I appreciate it.
I will try to resend the original db that I added to. I renamed it Age2.mdb. It has the same three expressions I have included over the last few days.
I think I have the right db attached. i am using two computers here at once because only one is correctly running Access and the other the internet.
The three expressions are:
AgeAccurateR1:Round((Date()-[DOB])/365.2425,1)
AgeAccurateR5:Round((Date()-[DOB])/365.2425,5)
AccurateAgeFix:Fix((Date()-[DOB])/365.2425)
Note:
1) There is no round () function with the Fix () function expression. The fix function trims the displayed result to no decimal places without any rounding.
2)The last record in the results table I posted earlier can only be obtained if you change your current computer date to 2/29/2012, so it conforms to Brian's example. That will also change all the other age calculations. I pasted the last record into a previous results table to show the effect, and not change any other records.
Changing your computer's current date is like entering a parameter for a "relevant" date, like an eligibility date, in an age calculation form. But it is much simpler for this purpose, because it does not include any other potentially confusing code.
OK; I think all is right. If not I will try again.
David
Thanks for your kind response. I appreciate it.
I will try to resend the original db that I added to. I renamed it Age2.mdb. It has the same three expressions I have included over the last few days.
I think I have the right db attached. i am using two computers here at once because only one is correctly running Access and the other the internet.
The three expressions are:
AgeAccurateR1:Round((Date()-[DOB])/365.2425,1)
AgeAccurateR5:Round((Date()-[DOB])/365.2425,5)
AccurateAgeFix:Fix((Date()-[DOB])/365.2425)
Note:
1) There is no round () function with the Fix () function expression. The fix function trims the displayed result to no decimal places without any rounding.
2)The last record in the results table I posted earlier can only be obtained if you change your current computer date to 2/29/2012, so it conforms to Brian's example. That will also change all the other age calculations. I pasted the last record into a previous results table to show the effect, and not change any other records.
Changing your computer's current date is like entering a parameter for a "relevant" date, like an eligibility date, in an age calculation form. But it is much simpler for this purpose, because it does not include any other potentially confusing code.
OK; I think all is right. If not I will try again.
David
ChrisO
Registered User.
- Local time
- Tomorrow, 05:30
- Joined
- Apr 30, 2003
- Messages
- 3,202
Congratulations, your results seem to confirm RainLovers calculations but do not seem to better them.
What is the benefit gained of such an exercise? It is a known fact that there are many ways to achieve the same end point from the same starting point in various endeavours. If the starting point and the ending point are equal then there seems to be nothing gained except for the method of getting there. If the method of getting there is the only difference then the method should be examined. It seems to me that the method of getting there has not been address by you and so leaves your replies no worse and no better than a reply that was made more than a month ago. (Give or take a few days.
)
In other words, in order to make a reply; what makes your method better?
Time is fickle.
We can walk down the street and ask someone; what time is it?
We can get an answer which makes perfect sense to us.
We pick up a phone and ask; what time is it?
We can get an answer which does not make perfect sense to us.
When we walk down the street, the person asking the question and the person answering the question are in the same place. We do not even ask if the place is the same, we assume it is. The answer makes sense to us because we have automatically assumed the same position and those assumptions cancel.
When we pick up the phone, the person asking the question and the person answering the question are not necessarily in the same place. Without further information we should not assume position and therefore we should not assume time.
We all know this as a fact yet seldom is it explained in simple language.
We run for the bus but miss it. We see the backend of the bus departing the bus stop. We see it and know exactly what happened. We think, and say, we were in the right place at the wrong time. It is perfectly natural to include place and time in the same thought. Had I been here earlier I would have caught the bus, I must be here earlier tomorrow.
Science often obfuscates the bleeding obvious. We know that we missed the bus by a few seconds; we will try to do better tomorrow. But science would try to tell us that we missed the bus in four dimensions, space time. Science is trying to tell us that we are bleeding idiots and we don’t know how to catch a bus.
In this case of catching a bus science is both correct and incorrect. Science is technically correct in explaining why we missed the bus. But science is incorrect in assuming that we need a technical explanation. In all practically we will catch the bus tomorrow and that is all that’s required.
David, you started your posts in this thread by stating:-
>>I have seen so much misinformation on the internet about age calculations.<<
Sure there is, the internet is full of misinformation about all sorts of things. But was there misinformation in the reply by RainLover which satisfied the original question in this thread?
Without being able to do better than the current posted solution by RainLover you are trying to reply in a purely mathematically manner. It is not a mathematical answer because Date() is 4D and DOB is 1D. When we subtract a 1D from a 4D that leaves 3D’s unknown and those 3D’s are positional.
Date(), as produced by a computer, is in 4D. In the case of the server for this site Date() is west coast USA time (+/- daylight saving). The date we see, when not logged in, is the date at the position of the server. But DOB has no positional information, it is simply 1D. If we subtract a 1D from a 4D the result of the calculation then becomes mathematically irrelevant (Unknown).
The missing of the bus is an event. When we miss the bus, we miss the bus by the product of the event; we miss the bus in the product of 4 dimensions. We miss the bus in space time. We are in the right place at the wrong time, we all know that. Tomorrow we will be on time and we will be in the same place. Tomorrow we will be correct in 4 dimensions. Tomorrow we will be in the right place at the right time and we will catch the bus.
Four dimensional space time is an event, we live and breathe it. We perceive it without even thinking about it. We either miss or catch the bus at a place, at a time.
A date, as returned by a computer, is in four dimensional space time, it is an event. It is this time and in this place of the computer. A date of birth is also an event, it happened in a place and at some time. But only one dimension of the birth event is known, time. Without the other three dimensions of the event, date of birth becomes unknown as an event. Date of birth needs all four dimensions to become an event. Just like catching the bus, we need all four dimensions to catch the event.
Calculations involving Date() (computer generated) – [DOB] are flawed. It is not because either Date() or DOB are inaccurate. It is because Date() (computer generated) is 4D and DOB is 1D. There is insufficient information to bring the 1D DOB up to the 4D Date() (computer generated).
As much as the attempt is made to increase the accuracy of the rotational speed of the Earth, or whatever, the result will remain flawed. It will remain flawed, not on the accuracy of such things, but on the very nature of trying to compare different dimensional quantities, 1D and 4D.
By all means try and write it some other way. But you may very well be reinventing a wheel that needs not reinventing. From my understanding, the date functions in Access are calculated to an accuracy of 10 microseconds. Internally the date/time data type has a resolution of ~100 nanoseconds (64 bit IEEE Double on days), but are apparently rounded by a factor of 1000 for storage. (Difficult to test.)
Good luck with future projects.
Chris.
What is the benefit gained of such an exercise? It is a known fact that there are many ways to achieve the same end point from the same starting point in various endeavours. If the starting point and the ending point are equal then there seems to be nothing gained except for the method of getting there. If the method of getting there is the only difference then the method should be examined. It seems to me that the method of getting there has not been address by you and so leaves your replies no worse and no better than a reply that was made more than a month ago. (Give or take a few days.
)In other words, in order to make a reply; what makes your method better?
Time is fickle.
We can walk down the street and ask someone; what time is it?
We can get an answer which makes perfect sense to us.
We pick up a phone and ask; what time is it?
We can get an answer which does not make perfect sense to us.
When we walk down the street, the person asking the question and the person answering the question are in the same place. We do not even ask if the place is the same, we assume it is. The answer makes sense to us because we have automatically assumed the same position and those assumptions cancel.
When we pick up the phone, the person asking the question and the person answering the question are not necessarily in the same place. Without further information we should not assume position and therefore we should not assume time.
We all know this as a fact yet seldom is it explained in simple language.
We run for the bus but miss it. We see the backend of the bus departing the bus stop. We see it and know exactly what happened. We think, and say, we were in the right place at the wrong time. It is perfectly natural to include place and time in the same thought. Had I been here earlier I would have caught the bus, I must be here earlier tomorrow.
Science often obfuscates the bleeding obvious. We know that we missed the bus by a few seconds; we will try to do better tomorrow. But science would try to tell us that we missed the bus in four dimensions, space time. Science is trying to tell us that we are bleeding idiots and we don’t know how to catch a bus.
In this case of catching a bus science is both correct and incorrect. Science is technically correct in explaining why we missed the bus. But science is incorrect in assuming that we need a technical explanation. In all practically we will catch the bus tomorrow and that is all that’s required.
David, you started your posts in this thread by stating:-
>>I have seen so much misinformation on the internet about age calculations.<<
Sure there is, the internet is full of misinformation about all sorts of things. But was there misinformation in the reply by RainLover which satisfied the original question in this thread?
Without being able to do better than the current posted solution by RainLover you are trying to reply in a purely mathematically manner. It is not a mathematical answer because Date() is 4D and DOB is 1D. When we subtract a 1D from a 4D that leaves 3D’s unknown and those 3D’s are positional.
Date(), as produced by a computer, is in 4D. In the case of the server for this site Date() is west coast USA time (+/- daylight saving). The date we see, when not logged in, is the date at the position of the server. But DOB has no positional information, it is simply 1D. If we subtract a 1D from a 4D the result of the calculation then becomes mathematically irrelevant (Unknown).
The missing of the bus is an event. When we miss the bus, we miss the bus by the product of the event; we miss the bus in the product of 4 dimensions. We miss the bus in space time. We are in the right place at the wrong time, we all know that. Tomorrow we will be on time and we will be in the same place. Tomorrow we will be correct in 4 dimensions. Tomorrow we will be in the right place at the right time and we will catch the bus.
Four dimensional space time is an event, we live and breathe it. We perceive it without even thinking about it. We either miss or catch the bus at a place, at a time.
A date, as returned by a computer, is in four dimensional space time, it is an event. It is this time and in this place of the computer. A date of birth is also an event, it happened in a place and at some time. But only one dimension of the birth event is known, time. Without the other three dimensions of the event, date of birth becomes unknown as an event. Date of birth needs all four dimensions to become an event. Just like catching the bus, we need all four dimensions to catch the event.
Calculations involving Date() (computer generated) – [DOB] are flawed. It is not because either Date() or DOB are inaccurate. It is because Date() (computer generated) is 4D and DOB is 1D. There is insufficient information to bring the 1D DOB up to the 4D Date() (computer generated).
As much as the attempt is made to increase the accuracy of the rotational speed of the Earth, or whatever, the result will remain flawed. It will remain flawed, not on the accuracy of such things, but on the very nature of trying to compare different dimensional quantities, 1D and 4D.
By all means try and write it some other way. But you may very well be reinventing a wheel that needs not reinventing. From my understanding, the date functions in Access are calculated to an accuracy of 10 microseconds. Internally the date/time data type has a resolution of ~100 nanoseconds (64 bit IEEE Double on days), but are apparently rounded by a factor of 1000 for storage. (Difficult to test.)
Good luck with future projects.
Chris.
Greetings:
The point, and a playful one to be sure, is that the calendar contains inherent measurement error, because it is of ancient origin, rooted in society and not science. The faithful representation of calendar age reproduces that error. That was the misinformation; calendar age is not accurate age. It is like saying that sometimes my yard stick has 34 inches, but other times it has 38. So if I then say something is 4 yards long, that is a combination of 34 inch yards and 38 inch yards. Only if I divide the total length in inches (assuming inches are the same) by 36 can I calculate the "accurate" length in yards. The DateDiff calculation will always contain the measurement error inherent in the calendar because calendar years are not the same length, whereas an actual year is..
The Date()-DOB/365.2425 calculation does not always return a result identical to the DateDiff calculation, as Brian's example implied. It just did for the data in the example table. In a non-leap year (this is a leap year) when a person reaches the first anniversary of their date of birth they are only 0.999337 years old (365/365.2425), not one year. Using the the fix function, the Date()-DOB/365.2425 returns zero not one. That is the difference improved accuracy makes.
The Date()-DOB/365.2425 is the more accurate calculation of age. It is not a perfect one given the lack of necessary information, when all you have is the date of birth, as you show conclusively, but it is still more accurate than calendar age. It could be made more accurate still if needed, and that would be more difficult with a DateDiff calculation.
If I understand correctly what you are saying about the four dimensions, the extra information needed would be time and place of birth (included on birth certificates), since you know where and when you are making the calculation. A look up table could adjust the date, time (including standard or daylight time), and place of birth to Greenwich mean time, and adjust the location and time of your calculation to Greenwich mean time. In this way, both DOB/time/place and calculation/location/date/time could be standardized to the common reference point of GMT. I am sure I could find such a look up table already made up if I looked hard enough.
All this reminds me of a Three Stooges episode where Curly had four watches on his arm to derive the accurate time. After a tediously lengthy explanation, Mo slapped him upside the head, poked him in the eyes with two fingers, and asked: "What time is it now?" Curly took another watch out of his pocket to answer the question. Is it splitting hairs? Perhaps, but division always splits hairs, whereas counting does not. Is it academic? Indeed. Alas, I am an academic, but not one who cannot laugh at himself, and not one who pretends to be perfect.
I think we have demonstrated that accurate age can be obtained using the Date()-DOB/accurate number of days per year, and that the result is more accurate than one based on DateDiff, and that using the fix function it can show the number of years without rounding. But I think I will still use Rainlover's calculation in most reports, unless a large percentage of my client's patients are enrolled in services on the day after the last calendar date of eligibility based on age (that is, their birthday), and there is much money at stake. I certainly do not want to have this conversation all the time.
Perhaps I shall include both calendar age and accurate age. Even though calendar age may appear in ordinary reports, accurate age will be present as a backup for negotiating with a provider whether a billing, based on an age-related eligibility date, is legitimate and should be paid. The difference between 0.999337 and 1.0 could make all the difference. Then, I would be happy to have this conversation again, if my client would receive thousands of dollars, otherwise lost because of an ineligible patient.
I have learned much in trying to explain this admittedly arcane point. My thanks to all for their insightful critiques. I am returning to programming my db.
Ciao
David
The point, and a playful one to be sure, is that the calendar contains inherent measurement error, because it is of ancient origin, rooted in society and not science. The faithful representation of calendar age reproduces that error. That was the misinformation; calendar age is not accurate age. It is like saying that sometimes my yard stick has 34 inches, but other times it has 38. So if I then say something is 4 yards long, that is a combination of 34 inch yards and 38 inch yards. Only if I divide the total length in inches (assuming inches are the same) by 36 can I calculate the "accurate" length in yards. The DateDiff calculation will always contain the measurement error inherent in the calendar because calendar years are not the same length, whereas an actual year is..
The Date()-DOB/365.2425 calculation does not always return a result identical to the DateDiff calculation, as Brian's example implied. It just did for the data in the example table. In a non-leap year (this is a leap year) when a person reaches the first anniversary of their date of birth they are only 0.999337 years old (365/365.2425), not one year. Using the the fix function, the Date()-DOB/365.2425 returns zero not one. That is the difference improved accuracy makes.
The Date()-DOB/365.2425 is the more accurate calculation of age. It is not a perfect one given the lack of necessary information, when all you have is the date of birth, as you show conclusively, but it is still more accurate than calendar age. It could be made more accurate still if needed, and that would be more difficult with a DateDiff calculation.
If I understand correctly what you are saying about the four dimensions, the extra information needed would be time and place of birth (included on birth certificates), since you know where and when you are making the calculation. A look up table could adjust the date, time (including standard or daylight time), and place of birth to Greenwich mean time, and adjust the location and time of your calculation to Greenwich mean time. In this way, both DOB/time/place and calculation/location/date/time could be standardized to the common reference point of GMT. I am sure I could find such a look up table already made up if I looked hard enough.
All this reminds me of a Three Stooges episode where Curly had four watches on his arm to derive the accurate time. After a tediously lengthy explanation, Mo slapped him upside the head, poked him in the eyes with two fingers, and asked: "What time is it now?" Curly took another watch out of his pocket to answer the question. Is it splitting hairs? Perhaps, but division always splits hairs, whereas counting does not. Is it academic? Indeed. Alas, I am an academic, but not one who cannot laugh at himself, and not one who pretends to be perfect.
I think we have demonstrated that accurate age can be obtained using the Date()-DOB/accurate number of days per year, and that the result is more accurate than one based on DateDiff, and that using the fix function it can show the number of years without rounding. But I think I will still use Rainlover's calculation in most reports, unless a large percentage of my client's patients are enrolled in services on the day after the last calendar date of eligibility based on age (that is, their birthday), and there is much money at stake. I certainly do not want to have this conversation all the time.
Perhaps I shall include both calendar age and accurate age. Even though calendar age may appear in ordinary reports, accurate age will be present as a backup for negotiating with a provider whether a billing, based on an age-related eligibility date, is legitimate and should be paid. The difference between 0.999337 and 1.0 could make all the difference. Then, I would be happy to have this conversation again, if my client would receive thousands of dollars, otherwise lost because of an ineligible patient.
I have learned much in trying to explain this admittedly arcane point. My thanks to all for their insightful critiques. I am returning to programming my db.
Ciao
David
