Date Comparison and Manipulation Functions?

[W. eWatson]

John Machin wrote:
> On Aug 30, 2:32 am, "W. eWatson" <notval... at sbcglobal.net> wrote:
>> I just tried the following code, and got an unexpected result.
>>
>> from pyfdate import *
>> t = Time()
>>
>> ts = Time(2008, 8, 29,15,20,7)
>> tnew = ts.plus(months=6)
>> print "new date: ", tnew
>>
>> Result:
>> new date:  2009-02-28 15:20:07
>>
>> I believe that should be April 1, 2009.
> 
> 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.
> 
>> If I use months = 1 and day =31, I
>> get Sept. 30, 2008 and not Oct. 1, 2008. Is there a way to get around this?
> 
> 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.

-- 
                                    W. Watson
              (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
               Obz Site:  39° 15' 7" N, 121° 2' 32" W, 2700 feet