It could only happen if at some point in time, some field or field we shorted and one or more fields were shortened by the same amount. If a simple algorithm could be devised to detect such cases beforehand, then CachedDateFormat is a winner.
I had mentioned "SS0" was a potentially malicious time format. In the code where PatternLayout creates the SimpleDateFormat, the format string could be sanity checked. If it appeared troublesome, then the SimpleDateFormat would not be wrapped with CachedDateFormat. If you wanted to be very careful, you'd get skip caching anything containing "G", "MMM", "E", "z" and things with only one or two "S".
Another approach would be to staleness date the millisecond field so that you don't trust it if it is, say, over a minute old.
Or probably better, redetermine the millisecond location if the length changed (the current criteria) or if the corresponding characters are not digits. You'd still need a guard that you either had "SSS" or no "S", but I think the additional check would make it extremely hard to trick the cache into making an invalidate date.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
