#1081 Bugs when DST (daylight savings time) changes

General (896)


recently I noticed a problem using the Seconds class and TimeSeries#add

When measuring during a change of the DST with the clock being set back you can get different Seconds objects for different java.util.Date objects but the Seconds instances have the same first millisecond, are equal (using the equals method), have the same hashcode and so on.

When for example calling TimeSeries#add(Second, double value) with such different seconds it internally calls the Seconds#compare to check that there is already no value for the argument RegularTimePeriod (Second in this case). But this fails when measuring for at least one hour and having such a change of the DST as described above.

At least it would be helpful to provide a hint to this problem in the exception thrown in TimeSeries#add.

Testcase (German locale / TimeZone):

public void testNewSeconds()
Second s1 = new Second(new Date(1288483983648L)); //Sun Oct 31 02:13:03 CEST 2010
Second s2 = new Second(new Date(1288487583648L)); //Sun Oct 31 02:13:03 CET 2010
Assert.assertFalse("Equal first millisecond!", s1.getFirstMillisecond() == s2.getFirstMillisecond()); //fails
Assert.assertFalse("Equal serial index!", s1.getSerialIndex() == s2.getSerialIndex()); //fails
Assert.assertFalse("Equal hash code!", s1.hashCode() == s2.hashCode()); //fails
TimeSeries t = new TimeSeries("test");
t.add(s1, 1.0);
t.add(s2, 1.0); //fails

If you can reproduce this problem, then it should be possible using TimeZone.setDefault / Locale.setDefault

I've tested again JFreeChart 1.0.13 and JFreeChart 1.0.14 but I haven't test for other RegularTimePeriods than Seconds. It might be the same problem there.

With regards


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks