Re: Adding Months to a date in assembly language


<randyhyde@xxxxxxxxxxxxx> wrote in message
news:1182885044.786673.288440@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Here's a routine that will add some number of months to a date in
assembly language.
Note that adding a month is not as trivial an operation as
incrementing the month field of the HLA data structure (and possibly
handling overflow into some other year):

type
daterec:
union

record
day :uns8;
month :uns8;
year :uns16;
endrecord;
date :dword;

endunion;


Consider, for example, what happens if you add one month to the date
1/31/2007. If you simply increment the month value, you wind up with
2/31/2007 which is an invalid date. Therefore, something has to be
done when adding one month to a date to ensure that you wind up with a
valid date.

To my knowledge, there is no standard, accepted, way of handling this.
Different people (and different library routines) handle this case in
different ways. For example, some algorithms add the number of days in
the current month to the date; for example, adding one month to
1/31/2007 would yield 3/3/2007 (because 2007 is not a leap year). I
have rejected that approach because 1+1 should equal 2, not 3 (that
is, Jan + one month should really be February).

Another approach I've seen is to add the number of days in the *next*
month to the current date. For example, 1/31/2007 plus one month would
properly yield 2/28/2007 using this scheme. However, that scheme fails
when you add 28 (the days in Feb, 2007) to 1/1/2007 (producing
1/29/2007, leaving you in January).

The approach I've gone with is to add the value to the month field
(updating the year field as necessary) and then checking the resulting
date. If the day field contains an inappropriate value for the new
month, I truncate it to the end of the month. Therefore, 1/31/2007 + 1
month would produce 2/31/2007, which I then truncate to 2/28/2007.

This solution is not perfect. If you add one month to a date and then
subtract one month from a date, you may not wind up with the date you
started with. However, as months contain a differing number of days
(depending on month and year), I'm willing to live with this anomaly.


<snip>

how about, we use what could be called a "mean month", which could be
defined as 30.4375 days.

or, 730.5 hours, 43830 minutes, or 2629800 seconds.

in this way, we uniformly move one 'month' in the future, wherever the exact
date happens to be...



.