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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
