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 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. _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
