On 3-May-07, at 9:49 AM, Dennis Birch wrote: > On 5/2/07, Steve Garman <[EMAIL PROTECTED]> wrote: >>> You don't think so what? That someone's birthday should be >>> assumed to >>> be in the past? >> >> Seems like a reasonable request to me. >> >> I've added optional parameter assumePastFuture >> >> leave it as zero for current century, so it still works as a drop-in >> replacement >> >> set it to a negative integer for the past or a positive integer >> for the >> future > > I just checked this out, and there's one major item I've noticed that > makes this not quite a drop-in replacement for ParseDate. > > If you call this function without first creating a new date you get a > NilObjectException, whereas ParseDate creates the date instance for > you. This is easily fixed by adding: > > if value = nil Then > value = new Date > end if
That would do it > I was also hoping that this routine would restore the old ParseDate > capability of interpreting an incomplete US-style date, e.g. "5/3" as > being that date in the current year: 5/3/2006. I'm going to see if I > can add that without messing things up too much. I'd suspect this request could be handled as well _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
