ADDITIONAL SYSTEM INFORMATION :
Applicable for all system
A DESCRIPTION OF THE PROBLEM :
When the user has set the user.timezone=Europe/Madrid, Java is calculating the timestamp for this particular date wrong: Jan 01 00:00:00 1901. It is including 14 min 44 seconds for this date. It is causing JDBC error message: "negative time" when we use with Oracle jdbc driver. It works fine for other dates/timings.
Only for this timezone and with this date, it is including leap seconds as well for the calculation. It is causing this issue.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the below program:
TimeZone.setDefault(TimeZone.getTimeZone("Europe/Madrid"));
GregorianCalendar c11 = new GregorianCalendar(1901,0,1,0,0,0);
System.out.println("Date created in Europe/Madrid: " + c11.getTime());
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Date created in Europe/Madrid:Tue Jan 01 00:00:00 CET 1901
ACTUAL -
Date created in Europe/Madrid: Tue Jan 01 00:14:44 CET 1901
You can see, it included 14 mins and 44 seconds (which is wrong)
CUSTOMER SUBMITTED WORKAROUND :
Use the timezone as Paris, it works almost all the scenarios.
FREQUENCY : always
Applicable for all system
A DESCRIPTION OF THE PROBLEM :
When the user has set the user.timezone=Europe/Madrid, Java is calculating the timestamp for this particular date wrong: Jan 01 00:00:00 1901. It is including 14 min 44 seconds for this date. It is causing JDBC error message: "negative time" when we use with Oracle jdbc driver. It works fine for other dates/timings.
Only for this timezone and with this date, it is including leap seconds as well for the calculation. It is causing this issue.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the below program:
TimeZone.setDefault(TimeZone.getTimeZone("Europe/Madrid"));
GregorianCalendar c11 = new GregorianCalendar(1901,0,1,0,0,0);
System.out.println("Date created in Europe/Madrid: " + c11.getTime());
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Date created in Europe/Madrid:Tue Jan 01 00:00:00 CET 1901
ACTUAL -
Date created in Europe/Madrid: Tue Jan 01 00:14:44 CET 1901
You can see, it included 14 mins and 44 seconds (which is wrong)
CUSTOMER SUBMITTED WORKAROUND :
Use the timezone as Paris, it works almost all the scenarios.
FREQUENCY : always