1934 Was Not Such A Good Year

[Gregory Lypny]

Well, I guess I'm wearing out my welcome with random precision as the  
popular song lyric goes.  And unless I'm experiencing a flashback,  
the centuryCutoff property does not do what it's definition says it  
will do.  It's just plain wrong!

 From the Revolution dictionary: "For example, if the centuryCutoff  
is set to 50, and the current year is 2000, then the date 4/12/51 is  
interpreted as being in the year 2051, while the date 4/12/50 is  
interpreted as being in 1950."

If centuryCutoff's default is 35 for 1935, then it's giving the  
opposite result where both 1934 and 34 are interpreted as 2034.   
Setting centuryCutoff to other values returns nonsense.  In the  
example at the bottom of this message, setting it to 50 as in the  
Revolution dictionary example, interprets 49 as 1913.  And the  
problem has nothing to do with setting the useSystemDate to true.

Can Revolution's date and time capabilities be trusted at all?  I  
think, as others have suggested, it's going to have to be home made  
functions and libraries for everything.

	Gregory

> I just want to confirm that Revolution does not recognize years
> before 1935.  The following handler converts a short date in 1934
> to it's long date and the result is 2034.
>
> 	Gregory
>
> set useSystemDate to true
> put "13/5/1934" into x
> if x is a date
> then
> put "Yes, it's a date."
> convert x to long date
> put return & x after msg
> else
> put "Nope."
> end if


Create this handler.

on mouseUp
   set useSystemDate to true
   set the centuryCutoff to 50
   put "12/4/51" into d1
   put "12/4/50" into d2
   put "12/4/49" into d3
   convert d1 to long date
   convert d2 to long date
   convert d3 to long date
   put "d1 =" && d1 & return & \
       "d2 =" && d2 & return & \
       "d3 =" && d3
end mouseUp

You get this result.

d1 = Thursday, April 12, 1951
d2 = Wednesday, April 12, 1950
d3 = Thursday, March 06, 1913