Hi, There are two things I think are wrong with the current implementation of TimeStampCacheValidity and in general with the way dealing with dates is done in Cocoon2. The first issues is that we are using a long instead of a Date to store and compare two dates. Java uses long to represent dates with a resolution of a millisecond starting from 1970, and thus has the year 2037 bug. We should be using Date instead of long, which supposedly should be safe from this problem. This problem pops up everywhere within the code, including in the Source class, and the TraxTransformer. The second issue is in the CacheValidity interface specification. Shouldn't the specification should actually say that the receiver object is valid if its timestamp is less than that of the parameter? Greetings, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://orion.nsr.hp.com/ (inside HP's firewall only) http://sourceforge.net/users/ovidiu/ (my SourceForge page) http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
