I have found that this is not related to Brazil tz at all, but to transtions to DST after 2038-01-19.
When time changes to DST, one hour is skipped. If a Date object is
created within this non-existent hour, java.util.Date adds 1 hour to
the given time to create a legal point in time. After 2038-01-19, due
to some bug in the JDK, 1 hour is subtracted instead. Since
java.sql.Date is an extension on java.util.Date and the fact that
Brazil changes to DST at 00:00:00 and that the time part in
java.util.Date of an java.sql.Date object is set to 00:00:00 1 hour
subtracted from the java.util.Date obect and ends up on 23:00:00 the
day before.
The same bug applies to all locales, but since most locales changes to
DST at 02:00:00 you will not see a date change. If you run the
following program:
package dateproblem;
import java.util.Date;
import java.util.TimeZone;
public class Main {
static void pDate(int y, int m, int d, int h, int min, int s, String z) {
TimeZone.setDefault(TimeZone.getTimeZone(z));
System.out.println(new Date(y - 1900, m - 1, d, h, min, s).toString());
}
public static void main(String[] args) {
pDate(2037, 3, 29, 2, 0, 0, "Europe/Oslo");
pDate(2038, 3, 28, 2, 0, 0, "Europe/Oslo");
}
}
You get the following output:
Sun Mar 29 03:00:00 CEST 2037
Sun Mar 28 01:00:00 CET 2038
And the last one has the same bug. One hour earlier instead of one
hour later. It does not help to use a Calendar object since that one
too builds upon the buggy java.util.Date implementation.
--
Bernt Marius Johnsen
signature.asc
Description: Digital signature
