> you uncovered a bug. > it is easier to try the following, using Script Debug Mode. > > on mouseUp > put "17.7.1901" into dateA > convert dateA from short system date to dateItems > end mouseUp > > and see 2001,7,17,2,0,0,3 . > > the same happens with the long system date and similarly with short and > long dates.
This is true, and is related to the centuryCutoff setting (which is by default "35" - any two digit date below 35 is 20xx, and below 35 is 19xx); for example, if I put this in the message box: convert "7/17/1934" to dateItems;put it I get this: 2034,7,17,2,0,0,2 But if I do this: convert "7/17/1935" to dateItems;put it I get an error: invalid date If I adjust the centuryCutoff to "36", and rerun the "convert 7/17/1935" code, I get: 2035,7,17,2,0,0,2 but trying to do it with "7/17/36" gets the same "invalid date" error. There is definitely some bugs in date management here... Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
