Time change isn't handled correctly

[yahrens]

When switching to DST ("Sommerzeit") in Europe/Berlin 2:30AM must not occur.

Test-rule:

FREQ=YEARLY;UNTIL=20200101T010101Z;BYMONTH=3;BYDAY=-1SU;BYHOUR=2;BYMINUTE=30

Test-case:

mTestRules.add(new TestRule("FREQ=YEARLY;UNTIL=20200101T010101Z;BYMONTH=3;BYDAY=-1SU;BYHOUR=2;BYMINUTE=30")
            .setStart("20120101T010101", "Europe/Berlin").setInstances(1));

Right now we get 9 instead of 1.

[gwijdegeenens]

This test rule describes the following :
Frequency : Jaarlijks
The last Sundag of the 3Rd month at 2:30 (UTC tijd)
Start 2012-01-01 01:01:01
End 2020-01-01 01:01:01

This should give the following 9 Dates instances
2012-01-01 // Start date is alway included
2012-03-25
2013-03-31
2014-03-30
2015-03-29
2016-03-27
2017-03-26
2018-03-25
2019-03-31

So I think 9 is a correct answer.
The .setInstances(1) is maybe wrong and that is maybe the reason why this test is in comment.

[dmfs]

The test specifies "Europe/Berlin" as the start time zone and the recurrence rule specifies the days at which the DST change occurs. On these days the clock is set forward from 2:00 to 3:00, so 2:30 is not a valid time. The general question is, how do we handle this case. Should we just generate these days (like we do currently)? Or should we skip them? Or should we throw an exception?