Manipulating Old Dates

[Ken Ray]

Rob,

In the product I'm working on with a client right now, we keep track of
birthdates. And the way we manage it is by setting the centuryCutoff to
one less than the current year (so right now it's "03"). This means that
as long as someone is 99 years old or less, we're OK. It's not a perfect
solution, but it's working so far.

Ken Ray
Sons of Thunder Software
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/ 

> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com 
> [mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of 
> Rob Cozens
> Sent: Saturday, February 07, 2004 9:18 AM
> To: How to use Revolution
> Subject: Manipulating Old Dates
> 
> 
> Several months ago I had a conversation with Ken Ray about the 
> shortcomings of Transcript's date manipulation commands when applied 
> to dates more than half a century old (or in the future).  I was 
> reminded of the issue when Douglas McKay wrote to tell me Serendipity 
> Library's validDate function did not work for the date he entered.
> 
> So I created a stack, a button, and a handler:
> 
> 	on mouseUp
> 		ask "Enter a date:"
> 		convert it to dateItems
> 		put "The converted date is"&&it
> 	end mouseUp
> 
> I took a day, Feb. 8, and ran the handler several times, changing the 
> year by a decade each time.
> 
>   	"2/8/44" yields "1944,8,2...
> 	"2/8/34" yields "2034,8,2...
> 	"2/8/1934" yields "2034,8,2...
> 
> The first two results are predictable, as the centuryCutoff property 
> defaults to 35.  The third result suggests to me that all date 
> conversion uses seconds as an intermediate conversion format (and 
> probably that is why one can add to the seconds, days, and months and 
> get a correct date WITHIN THE RANGE OF THE CENTURY CUTOFF).
> 
> So just how does one work around this shortcoming, especially when 
> dealing with current & past dates concurrently?  For example, I have 
> a stack that charts biorhythms from any date based on the subject's 
> dob.  Normally, biorhythms are charted from a current date a few 
> months into the future; so one would expect the starting date to work 
> with a centuryCutoff of 35 (until 2036).  But what of birth dates? 
> Again, biorhythms are normally charted for living persons, not 
> historical figures; but even so there are people alive today that 
> could have been born in the 19th, 20th, or 21st centuries.
> 
> How does one deal with these issues given Transcript's date 
> handling commands?
> 
> And isn't the centuryCutoff property setting developers up for "baby 
> Y2K" conversion issues as the default centuryCutoff approaches?
> 
> When Ken & I spoke, we discussed the need for Julian date handlers in 
> Transcript.  I have Julian date routines in my old FORTRAN & PL/1 
> libraries.  Is it time they were incorporated into Serendipity 
> Library?
> 
> Rob Cozens
> CCW, Serendipity Software Company http://www.oenolog.net/who.htm
> 
> "And I, which was two fooles, do so grow three;
> Who are a little wise, the best fooles bee."
> 
> from "The Triple Foole" by John Donne (1572-1631) 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com 
> http://lists.runrev.com/mailman/listinfo/use-> revolution
>