Date calculation bug and workaround
Tip version: 44.2
Modified date: 14 May 2001
Software version: v5.2 and above
I have recognized that there is a bug in the date calculation feature used in the events. [This bug may well have been reported by others to the list in the past. If so, my apologies for not recalling those posts.]
The bug appears when you are calculating a date backwards from another date. An example of this is when you have the date of a person's death and their age at death (so many years, months, and days). The problem only appears when your start date is at or near the end of a month and the destination month (that resulting from the calculation) has fewer days than the source month. In other words, the source day you start from is not present in the destination month.
Consider the following example:
Forward calculation. A child is born on 29 June 1999. The year is not relevant. The child lives for 1 month and 2 days. Enter the child's birth on the person card. Then, for the child's death enter "1 month 2 days after birth." The program correctly calculates that the date of death is 31 July 1999.
Reverse calculation. Start with entering the date of death, 31 July 1999. Enter the child's birth as "1 month 2 days before death." The program will not return with the result of 29 June 1999 but instead reports that the date format is incorrect, displaying a calculated date of 31 June 1999!
As far as I have been able to determine, this problem always occurs when you are doing a backwards calculation in similar circumstances: starting at a day in the origin month which does not exist in the destination month. It makes no difference in the above example whether the age used for the child is 1 month and 2 days or 1 month and 20 days, as just two instances. As far as the program is concerned in this calculation, a person dying on 31 July 1999 cannot have been born in June or any other month with less than 31 days, at least if the birthdate is calculated from an age at death. Note that in the trivial example above, one could actually do the reverse calculation using 32 days (30 days for the month of June, plus 2 days), i.e. entering the date as "32 days before death." This is accepted and calculated properly. But this is obviously not practical in most circumstances (e.g. "58 years 9 months 11 days before death").
Workaround: This is a very crude workaround but is the only one I have at the moment.
Alter the date of death (or other event used for the calculation) downwards by a couple of days so that it is in the range of dates for all months.
Do the reverse date calculation (no date feasibility warning will be generated).
Adjust the calculated date and the source date upward by the amount you subtracted earlier.
This problem has been reported to Sierra. The problem obviously derives from the choice of where and when during the calculation of the dates the feasibility check is applied.
Regards, Mike Hobart
Copyright © 1999-2001 Michael A. Hobart, commercial reuse restricted.