John said:
Presuming that we are talking about the Gregorian calendar, and not
one of your own invention, you are (one trusts) alone in that belief.
There are SEVEN whole months and a bit between August 29, 2008 and
April 1, 2009. Count the months: Sep, Oct, Nov, Dec, Jan, Feb, Mar.
Because the number of days in a month is not constant, adding a number
of months to a date is capable of more than one interpretation. Most
folk are happy with adding the months on and then ensuring that the
day is not later than the last day of the resultant (year, month)
combination -- this is what the pyfdate routine appears to be doing.
However there are some interesting ideas floating around e.g. IIRC an
eminent personage once asserted in this newsgroup that adding 1 month
to 31 Jan in a non-leap year should produce 3 Mar.
There is also the general question with date intervals of whether the
first day is included in the calculation or not. E.g. work on Monday,
Tuesday, Wednesday: that's 3 days service. Put money into the bank on
Monday, withdraw it on Wednesday: that's likely to attract 2 days
interest.
One needs to understand exactly what calculation is required, and
exactly what calculation is provided by the software that is proposed
to be used.
HTH,
John
What I'm trying to do is adjust date-time stamped file names for date and
time errors. The software program collects through a period that roughly
coincides with night hours every day and according to the OS clock. It
sometimes happens that a user sets the clock to the wrong day or hour,
possibly both. Possibly even the month or year. I'm trying to allow a user
the opportunity to repair the problem. (Date-time stamp part of the name is
yyyymmdd_hhmmss.) Correcting the date needs to be done easily and
accurately. For example, if on August 25, he mistakenly sets the date to
July 25, and discovers this problem on the real Oct. 5, he should be able to
shift all dates from July 25 through Sept. 5 to Aug. 25 through early Oct.,
allowing for day oddities in a month during the period. (I hope I got those
dates right; otherwise, I think you get the idea. In other words, he needs
to shift about 40 days of data to the correct dates.) Or:
True calendar period: August 25 to Oct. 5
Recorded calendar period: July 25 to Sept. 5 (roughly 5)
A second function is to correct the time stamp for drift in the clock. For
this, I'm expecting the user knows the daily drift, +/-, in seconds of the
clock. When he decides, for example, that he's let the clock drift for more
than, say, 120 seconds, he may want to adjust the time stamp for all files
collected since the last time he set the clock properly. About the best
anyone can hope for is that the data is accurate to within 4 to 5 seconds,
so over periods of say a month between adjustments this should be OK. The
computers used do not have time data other than that provided by the h/w
clock on the computer. This method is not meant to be a cure all, just to
get the time stamp within a reasonable value. Personally, I reset the time
about every 2-3 weeks. Problems that arise here are associated with working
near midnight. Again, it's possible to set some time or date component
incorrectly each time one needs to get drift under control.
The OSes involved can be Win XP, Win 2000, or even older Win OSes, varieties
of Apple and Linux. I don't want to go below the level of the simple h/w
clock a typical user might have access to through the OS s/w user interface.
However, I do not need to get into OS details to solve the above problems.
There are of course times when a mistaken setting is caught early, so the
adjustment becomes easy. Suppose the day is taken as May 3 on May 5, and two
days later the mistake is noticed. Changing the date for these files is
pretty easy (with the program).
Well, back to the drawing board for awhile to see how this plays against
pyfdate.
