A couple of sundry bugs to report :
1) If a org.jfree.data.time.Week object is created with a TimeZone that is different from the DEFAULT_TIME_ZONE, the value returned by the getXXXXMilliSecond() calls seem to be incorrect. (Corresponds to the default TimeZone).
("new Week(date).getFirstMilliSeconds()" will return the same value as "new Week(date,anotherTimeZone).getFirstMilliSeconds()" which isn't correct behaviour).
On quick look, this appears to be because the computation is based on SerialDates (which don't seem to have a concept of TimeZones ??). The millisecond values are read from a Day object constructed using the SerialDate (and hence no TimeZone). I think the correct thing to do is to construct the Day object using the TimeZone of the Calendar and then read time from it.
2) In the ChartPanel class - paintComponent method, the Graphics2D object that is created from the Offscreen BufferedImage is not being disposed. There must be a "bufferG2.dispose()" call somewhere around line 887.
Similarly, it may be (??) better to call flush() on the bufferedImage object (chartBuffer) if it is non-null and you need to reconstruct it. The flush() for images is a poorly documented feature, so one is not very sure whether not calling it can create any resource leaks or not - but it is probably safer to call it rather than not.
BK
Sundry bugs
Sorry for the false alarm. On going through the sources of other classes in the data.time package, realized that the the TimeZone parameter that is passed in the constructor isn't really kept track of by any of the RegularTimePeriod descendants, and hence it is upto the user to keep track of the TimeZone which is being used. So it isn't really a bug , it is so by design 
BK
BK