FULL PRODUCT VERSION :


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601] (does not seem to be OS dependent).

A DESCRIPTION OF THE PROBLEM :
Moving back across the autumn DST change and then calling the set methods gives the wrong result.

See the attached source code.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Using GregorianCalendar:
Start with at time just after the autumn DST (2014-26-10 02:00 CET).
Subtract one hour (should get 2014-26-10 02:00 CEST).
Set the minutes to zero

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The time should be unchanged since the minutes already was zero.
ACTUAL -
Time jumps forward to 2014-26-10 02:00 CET.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package com.conscius.cpt.core.dates;

import java.util.Calendar;
import java.util.TimeZone;

public class CalendarBug {
    public static void main(String[] args) {
        Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("CET"));

        cal.set(Calendar.YEAR, 2014);
        cal.set(Calendar.MONTH, Calendar.OCTOBER);
        cal.set(Calendar.DAY_OF_MONTH, 26);
        cal.set(Calendar.HOUR_OF_DAY, 2);
        cal.set(Calendar.MINUTE, 0);
        cal.set(Calendar.SECOND, 0);
        cal.set(Calendar.MILLISECOND, 0);

        System.out.println(cal.getTimeInMillis()); // 1414285200000 : 01:00:00 UTC

        cal.add(Calendar.HOUR_OF_DAY, -1);

        System.out.println(cal.getTimeInMillis()); // 1414281600000 : 00:00:00 UTC (as expected)

        cal.set(Calendar.MINUTE, 0);
        // or: cal.set(Calendar.MINUTE, cal.get(Calendar.MINUTE));
        // both should be NOPs.

        System.out.println(cal.getTimeInMillis()); // 1414285200000 : 01:00:00 UTC (Why?!)
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
cal.add(Calendar.MINUTE, -cal.get(Calendar.MINUTE)) works.