You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Thomas Mueller <th...@gmail.com> on 2008/10/31 15:20:51 UTC
Date 2042-10-12 problem using Brasilia time zone
Hi,
I am implementing the Java database engine H2 (www.h2database.com - a
competitor of Apache Derby and HSQLDB).
I user of my database in Brasil recently found a problem with the date
2042-10-12. In Brasil, at that day, the time 00:00:00 (midnight)
doesn't 'exist' because it is the end of the daylight saving time. It
looks like this is a problem of java.sql.Date:
java.sql.Date.valueOf("2042-10-12").toString();
> 2042-10-11
This happens when using the timezone Brasilia. I tried with JDK
1.6.0_05 but I guess that happens on all version of Java. I use
Windows XP but again I don't think this is the problem. I also noticed
for Apache Derby and HSQLDB:
create table test(d date);
insert into test values('2042-10-12');
select d, cast(d as varchar(255)) from test;
> 2042-10-11 2042-10-11
drop table test;
I think that Java sets the time to 11:00:00 of the previous day. That
might be technically correct, but I hope you agree it's a problem.
What I plan to do in my database engine is to set the time to 12:00:00
(midday). Unfortunately this breaks a few things, like equality of
java.sql.Date that are returned by H2 and dates that are created by
java.sql.Date.valueOf, but I don't know how to solve the problem
otherwise (short term). Long term, an option might be to fix the
problem in java.sql.Date.
I hope that we Java database implementors (Apache Derby, HSQLDB, H2)
find a common solution to that problem. I also wrote this message to
HSQLDB at http://sourceforge.net/forum/message.php?msg_id=5548088
What do you think would be the best solution?
Regards,
Thomas
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
Thank! So it looks like a problem in java.util.Date, like Lance
Andersen predicted. Good to know! First I thought this is a planned
DST rule change, and java.sql.Date is just a 'victim' of that...
Anyway I found a 'partial' workaround (until the bug is fixed):
increase the time by 6 hours.
As soon as I can submit more information to the JSE bug I will do so.
Regards,
Thomas
On Tue, Nov 4, 2008 at 8:09 PM, Bernt M. Johnsen <Be...@sun.com> wrote:
> 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJEJ3OlFBD9TXBAPARAvoxAJ9X+0+JzDUAPhQJkoqga4eT93+BFQCfbKW5
> 8CRrjGX2ISA9qUj6djuiez0=
> =ySTA
> -----END PGP SIGNATURE-----
>
>
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
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
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> Bernt M. Johnsen wrote (2008-10-31 15:45:18):
> Although I can't shed any light on the Java/JavaDB problem, I can
> clarify a bit on DST and Brazil. Brazil decided by law 2008-09-08 that
> at 00:00 the third Sunday in October (which is 2008-10-18) is the
> change from DST to normal time and at 00:00 the third Sunday of
> February they will change back to DST.
The other way around of course, since this is south of equator.
> If your JDK is older than > 2008-09-08, is is likely that it won't
> do this correct.
>
> And, in 2042, the change will be on 2042-10-19 according to the new
> law.
>
>
> >>>>>>>>>>>> Mark Thornton wrote (2008-10-31 14:31:18):
> > Thomas Mueller wrote:
> >> What I plan to do in my database engine is to set the time to 12:00:00
> >> (midday). Unfortunately this breaks a few things, like equality of
> >> java.sql.Date that are returned by H2 and dates that are created by
> >> java.sql.Date.valueOf, but I don't know how to solve the problem
> >> otherwise (short term). Long term, an option might be to fix the
> >> problem in java.sql.Date.
> >>
> >
> > The long term solution is probably jsr310 which replaces all the
> > date/time classes with something more rational.
> >
> > Mark Thornton
>
> --
> Bernt Marius Johnsen, Staff Engineer
> Database Technology Group, Sun Microsystems, Trondheim, Norway
--
Bernt Marius Johnsen, Staff Engineer
Database Technology Group, Sun Microsystems, Trondheim, Norway
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> Bernt M. Johnsen wrote (2008-11-04 16:55:47):
> Played around with java.util.Date and found that it is done correctly
> up to and including 2037 and errouneously from 2038.
That is, given that the change to DST for Brazil is the second Sunday
in October, which is also wrong. It's now (from 2008) the 3rd Sunday
in October.
> I don't think it's a coincidence that the 32-bit number of seconds
> since 1970-01-01 expires (or wraps around) on 2038-01-19.......
>
> --
> Bernt Marius Johnsen, Staff Engineer
> Database Technology Group, Sun Microsystems, Trondheim, Norway
--
Bernt Marius Johnsen, Staff Engineer
Database Technology Group, Sun Microsystems, Trondheim, Norway
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
Played around with java.util.Date and found that it is done correctly
up to and including 2037 and errouneously from 2038. I don't think
it's a coincidence that the 32-bit number of seconds since 1970-01-01
expires (or wraps around) on 2038-01-19.......
--
Bernt Marius Johnsen, Staff Engineer
Database Technology Group, Sun Microsystems, Trondheim, Norway
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by Lance Andersen <La...@Sun.COM>.
On Nov 4, 2008, at 8:10 AM, Thomas Mueller wrote:
> Hi,
>
>> this is *not* an issue with java.sql.Date.
>
> I am not sure about that.
java.sql.Date is nothing but a wrapper to java.util.Date, so what you
pass in to the valueOf get passed directly to the constructor of
java.util.Date(int,int, int). All of the work is done in
java.util.Date.
Regards
Lance
>
>
>> java.sql.Date.valueOf() calls java.util.Date(int,int,int) and if
>> you modify
>> your test program, you will see the same results from java.util.Date.
>
> I submitted the problem even without knowing the exact root cause. If
> you found the root cause of the problem, or if you even know how to
> fix it, that would be great of course!
>
> It looks like midnight of that day doesn't exist because it is the
> beginning or end of the daylight saving time. Where I live this change
> occurs at 2 am, but in some countries the change is at or near
> midnight. From what I know, java.util.Calendar doesn't allow to set
> 'invalid' hours, and if using the lenient setting it will 'fix' the
> time. Maybe the reason is that midnight of that day is set to 11 pm of
> the previous day. This change may be the expected behavior of
> java.util.Date / Calendar, but for java.sql.Date it is a problem. So
> maybe it is required to fix java.sql.Date, not java.util.Date. But I
> am not sure because I didn't debug it so far.
>
>> Please update any submitted bug
>
> I don't see a way to update the bug. I got a mail saying: "Your report
> has been assigned an internal review ID of 1384760, which is NOT
> visible on the Sun Developer Network (SDN)". There is no link.
>
> Regards,
> Thomas
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
> this is *not* an issue with java.sql.Date.
I am not sure about that.
> java.sql.Date.valueOf() calls java.util.Date(int,int,int) and if you modify
> your test program, you will see the same results from java.util.Date.
I submitted the problem even without knowing the exact root cause. If
you found the root cause of the problem, or if you even know how to
fix it, that would be great of course!
It looks like midnight of that day doesn't exist because it is the
beginning or end of the daylight saving time. Where I live this change
occurs at 2 am, but in some countries the change is at or near
midnight. From what I know, java.util.Calendar doesn't allow to set
'invalid' hours, and if using the lenient setting it will 'fix' the
time. Maybe the reason is that midnight of that day is set to 11 pm of
the previous day. This change may be the expected behavior of
java.util.Date / Calendar, but for java.sql.Date it is a problem. So
maybe it is required to fix java.sql.Date, not java.util.Date. But I
am not sure because I didn't debug it so far.
> Please update any submitted bug
I don't see a way to update the bug. I got a mail saying: "Your report
has been assigned an internal review ID of 1384760, which is NOT
visible on the Sun Developer Network (SDN)". There is no link.
Regards,
Thomas
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by Lance Andersen <La...@Sun.COM>.
Also,
this is *not* an issue with java.sql.Date.
java.sql.Date.valueOf() calls java.util.Date(int,int,int) and if you
modify your test program, you will see the same results from
java.util.Date. Please update any submitted bug to reference
java.util.Date accordingly and validate as Bernt states that TZupdater
does/does not addresss your problem and indicate that in the bug.
On Nov 4, 2008, at 3:21 AM, Bernt M. Johnsen wrote:
> Hav you tried the tzupdater to see if the lates version of tzdata
> fixes the problem? tzdata2008g/TZupdater 1.3.9 is newer than JRE 6u10
> and contains changes for Brazil.
>
>
>>>>>>>>>>>>> Thomas Mueller wrote (2008-11-03 18:41:03):
>> Hi,
>>
>> I submitted a bug in JSE.
>>
>> Regards,
>> Thomas
>>
>>
>> On Sat, Nov 1, 2008 at 3:00 AM, Dag H. Wanvik <Da...@sun.com>
>> wrote:
>>> Thomas Mueller <th...@gmail.com> writes:
>>>
>>> I got the same result on my box,
>>>
>>> 1.6.0_10-beta-b24
>>> SunOS
>>> :
>>>
>>> Dag
>>>
>>>
>>>> Hi,
>>>>
>>>> I just made a simple test case. Could you please run that and
>>>> post the result?
>>>>
>>>> import java.sql.Date;
>>>> import java.util.TimeZone;
>>>> public class DateProblem {
>>>> public static void main(String[] a) {
>>>>
>>>> System.out.println(System.getProperty("java.runtime.version"));
>>>> System.out.println(System.getProperty("os.name"));
>>>> String[] ids = TimeZone.getAvailableIDs();
>>>> for (int i = 0; i < ids.length; i++) {
>>>> TimeZone.setDefault(TimeZone.getTimeZone(ids[i]));
>>>> for (int y = 2037; y < 2039; y++) {
>>>> for (int m = 101; m < 113; m++) {
>>>> for (int d = 101; d < 129; d++) {
>>>> test(y, m, d);
>>>> }
>>>> }
>>>> }
>>>> }
>>>> }
>>>> static void test(int y, int m, int d) {
>>>> String s = y + "-" + ("" + m).substring(1) + "-" + ("" +
>>>> d).substring(1);
>>>> String s2 = Date.valueOf(s).toString();
>>>> if (!s.equals(s2)) {
>>>> String e = "java.sql.Date.valueOf(\"" + s + "\"): \""
>>>> + s2 + "\"";
>>>> e += " TimeZone: " + TimeZone.getDefault().getID();
>>>> System.out.println(e);
>>>> }
>>>> }
>>>> }
>>>>
>>>> I get:
>>>> 1.6.0_05-b13
>>>> Windows XP
>>>> java.sql.Date.valueOf("2038-03-14"): "2038-03-13" TimeZone:
>>>> America/Havana
>>>> java.sql.Date.valueOf("2038-03-14"): "2038-03-13" TimeZone: Cuba
>>>> java.sql.Date.valueOf("2038-10-17"): "2038-10-16" TimeZone:
>>>> America/Asuncion
>>>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone:
>>>> America/Campo_Grande
>>>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone:
>>>> America/Cuiaba
>>>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone:
>>>> America/Santiago
>>>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone:
>>>> Antarctica/Palmer
>>>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: Chile/
>>>> Continental
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: AGT
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Argentina/Buenos_Aires
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Argentina/Catamarca
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Argentina/ComodRivadavia
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Argentina/Cordoba
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Argentina/Jujuy
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Argentina/La_Rioja
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Argentina/Mendoza
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Argentina/Rio_Gallegos
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Argentina/San_Juan
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Argentina/Tucuman
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Argentina/Ushuaia
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Buenos_Aires
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Catamarca
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Cordoba
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Jujuy
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Mendoza
>>>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>>>> America/Rosario
>>>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone:
>>>> America/Sao_Paulo
>>>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: BET
>>>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone:
>>>> Brazil/East
>>>> java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone:
>>>> America/Scoresbysund
>>>> java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone:
>>>> Atlantic/Azores
>>>> java.sql.Date.valueOf("2038-03-25"): "2038-03-24" TimeZone: Asia/
>>>> Amman
>>>> java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone: Asia/
>>>> Beirut
>>>> java.sql.Date.valueOf("2038-03-26"): "2038-03-25" TimeZone: Asia/
>>>> Damascus
>>>> java.sql.Date.valueOf("2038-04-01"): "2038-03-31" TimeZone: Asia/
>>>> Gaza
>>>> java.sql.Date.valueOf("2038-03-21"): "2038-03-20" TimeZone: Asia/
>>>> Tehran
>>>> java.sql.Date.valueOf("2038-03-21"): "2038-03-20" TimeZone: Iran
>>>>
>>>> Regards,
>>>> Thomas
>>>>
>>>
>>> --
>>> Dag H. Wanvik, staff engineer
>>> Sun Microsystems, Databases (JavaDB/Derby)
>>> Haakon VII gt. 7b, N-7485 Trondheim, Norway
>>> Tel: x43496/+47 73842196, Fax: +47 73842101
>>>
>
> --
> Bernt Marius Johnsen, Staff Engineer
> Database Technology Group, Sun Microsystems, Trondheim, Norway
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
> Hav you tried the tzupdater to see if the lates version of tzdata
> fixes the problem? tzdata2008g/TZupdater 1.3.9 is newer than JRE 6u10
> and contains changes for Brazil.
I just tried - it doesn't help.
Regards,
Thomas
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
Hav you tried the tzupdater to see if the lates version of tzdata
fixes the problem? tzdata2008g/TZupdater 1.3.9 is newer than JRE 6u10
and contains changes for Brazil.
>>>>>>>>>>>> Thomas Mueller wrote (2008-11-03 18:41:03):
> Hi,
>
> I submitted a bug in JSE.
>
> Regards,
> Thomas
>
>
> On Sat, Nov 1, 2008 at 3:00 AM, Dag H. Wanvik <Da...@sun.com> wrote:
> > Thomas Mueller <th...@gmail.com> writes:
> >
> > I got the same result on my box,
> >
> > 1.6.0_10-beta-b24
> > SunOS
> > :
> >
> > Dag
> >
> >
> >> Hi,
> >>
> >> I just made a simple test case. Could you please run that and post the result?
> >>
> >> import java.sql.Date;
> >> import java.util.TimeZone;
> >> public class DateProblem {
> >> public static void main(String[] a) {
> >> System.out.println(System.getProperty("java.runtime.version"));
> >> System.out.println(System.getProperty("os.name"));
> >> String[] ids = TimeZone.getAvailableIDs();
> >> for (int i = 0; i < ids.length; i++) {
> >> TimeZone.setDefault(TimeZone.getTimeZone(ids[i]));
> >> for (int y = 2037; y < 2039; y++) {
> >> for (int m = 101; m < 113; m++) {
> >> for (int d = 101; d < 129; d++) {
> >> test(y, m, d);
> >> }
> >> }
> >> }
> >> }
> >> }
> >> static void test(int y, int m, int d) {
> >> String s = y + "-" + ("" + m).substring(1) + "-" + ("" +
> >> d).substring(1);
> >> String s2 = Date.valueOf(s).toString();
> >> if (!s.equals(s2)) {
> >> String e = "java.sql.Date.valueOf(\"" + s + "\"): \"" + s2 + "\"";
> >> e += " TimeZone: " + TimeZone.getDefault().getID();
> >> System.out.println(e);
> >> }
> >> }
> >> }
> >>
> >> I get:
> >> 1.6.0_05-b13
> >> Windows XP
> >> java.sql.Date.valueOf("2038-03-14"): "2038-03-13" TimeZone: America/Havana
> >> java.sql.Date.valueOf("2038-03-14"): "2038-03-13" TimeZone: Cuba
> >> java.sql.Date.valueOf("2038-10-17"): "2038-10-16" TimeZone: America/Asuncion
> >> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Campo_Grande
> >> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Cuiaba
> >> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Santiago
> >> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: Antarctica/Palmer
> >> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: Chile/Continental
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: AGT
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> >> America/Argentina/Buenos_Aires
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> >> America/Argentina/Catamarca
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> >> America/Argentina/ComodRivadavia
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> >> America/Argentina/Cordoba
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> >> America/Argentina/Jujuy
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> >> America/Argentina/La_Rioja
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> >> America/Argentina/Mendoza
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> >> America/Argentina/Rio_Gallegos
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> >> America/Argentina/San_Juan
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> >> America/Argentina/Tucuman
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> >> America/Argentina/Ushuaia
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Buenos_Aires
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Catamarca
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Cordoba
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Jujuy
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Mendoza
> >> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Rosario
> >> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Sao_Paulo
> >> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: BET
> >> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: Brazil/East
> >> java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone: America/Scoresbysund
> >> java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone: Atlantic/Azores
> >> java.sql.Date.valueOf("2038-03-25"): "2038-03-24" TimeZone: Asia/Amman
> >> java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone: Asia/Beirut
> >> java.sql.Date.valueOf("2038-03-26"): "2038-03-25" TimeZone: Asia/Damascus
> >> java.sql.Date.valueOf("2038-04-01"): "2038-03-31" TimeZone: Asia/Gaza
> >> java.sql.Date.valueOf("2038-03-21"): "2038-03-20" TimeZone: Asia/Tehran
> >> java.sql.Date.valueOf("2038-03-21"): "2038-03-20" TimeZone: Iran
> >>
> >> Regards,
> >> Thomas
> >>
> >
> > --
> > Dag H. Wanvik, staff engineer
> > Sun Microsystems, Databases (JavaDB/Derby)
> > Haakon VII gt. 7b, N-7485 Trondheim, Norway
> > Tel: x43496/+47 73842196, Fax: +47 73842101
> >
--
Bernt Marius Johnsen, Staff Engineer
Database Technology Group, Sun Microsystems, Trondheim, Norway
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
I submitted a bug in JSE.
Regards,
Thomas
On Sat, Nov 1, 2008 at 3:00 AM, Dag H. Wanvik <Da...@sun.com> wrote:
> Thomas Mueller <th...@gmail.com> writes:
>
> I got the same result on my box,
>
> 1.6.0_10-beta-b24
> SunOS
> :
>
> Dag
>
>
>> Hi,
>>
>> I just made a simple test case. Could you please run that and post the result?
>>
>> import java.sql.Date;
>> import java.util.TimeZone;
>> public class DateProblem {
>> public static void main(String[] a) {
>> System.out.println(System.getProperty("java.runtime.version"));
>> System.out.println(System.getProperty("os.name"));
>> String[] ids = TimeZone.getAvailableIDs();
>> for (int i = 0; i < ids.length; i++) {
>> TimeZone.setDefault(TimeZone.getTimeZone(ids[i]));
>> for (int y = 2037; y < 2039; y++) {
>> for (int m = 101; m < 113; m++) {
>> for (int d = 101; d < 129; d++) {
>> test(y, m, d);
>> }
>> }
>> }
>> }
>> }
>> static void test(int y, int m, int d) {
>> String s = y + "-" + ("" + m).substring(1) + "-" + ("" +
>> d).substring(1);
>> String s2 = Date.valueOf(s).toString();
>> if (!s.equals(s2)) {
>> String e = "java.sql.Date.valueOf(\"" + s + "\"): \"" + s2 + "\"";
>> e += " TimeZone: " + TimeZone.getDefault().getID();
>> System.out.println(e);
>> }
>> }
>> }
>>
>> I get:
>> 1.6.0_05-b13
>> Windows XP
>> java.sql.Date.valueOf("2038-03-14"): "2038-03-13" TimeZone: America/Havana
>> java.sql.Date.valueOf("2038-03-14"): "2038-03-13" TimeZone: Cuba
>> java.sql.Date.valueOf("2038-10-17"): "2038-10-16" TimeZone: America/Asuncion
>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Campo_Grande
>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Cuiaba
>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Santiago
>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: Antarctica/Palmer
>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: Chile/Continental
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: AGT
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>> America/Argentina/Buenos_Aires
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>> America/Argentina/Catamarca
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>> America/Argentina/ComodRivadavia
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>> America/Argentina/Cordoba
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>> America/Argentina/Jujuy
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>> America/Argentina/La_Rioja
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>> America/Argentina/Mendoza
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>> America/Argentina/Rio_Gallegos
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>> America/Argentina/San_Juan
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>> America/Argentina/Tucuman
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
>> America/Argentina/Ushuaia
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Buenos_Aires
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Catamarca
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Cordoba
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Jujuy
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Mendoza
>> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Rosario
>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Sao_Paulo
>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: BET
>> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: Brazil/East
>> java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone: America/Scoresbysund
>> java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone: Atlantic/Azores
>> java.sql.Date.valueOf("2038-03-25"): "2038-03-24" TimeZone: Asia/Amman
>> java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone: Asia/Beirut
>> java.sql.Date.valueOf("2038-03-26"): "2038-03-25" TimeZone: Asia/Damascus
>> java.sql.Date.valueOf("2038-04-01"): "2038-03-31" TimeZone: Asia/Gaza
>> java.sql.Date.valueOf("2038-03-21"): "2038-03-20" TimeZone: Asia/Tehran
>> java.sql.Date.valueOf("2038-03-21"): "2038-03-20" TimeZone: Iran
>>
>> Regards,
>> Thomas
>>
>
> --
> Dag H. Wanvik, staff engineer
> Sun Microsystems, Databases (JavaDB/Derby)
> Haakon VII gt. 7b, N-7485 Trondheim, Norway
> Tel: x43496/+47 73842196, Fax: +47 73842101
>
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Thomas Mueller <th...@gmail.com> writes:
I got the same result on my box,
1.6.0_10-beta-b24
SunOS
:
Dag
> Hi,
>
> I just made a simple test case. Could you please run that and post the result?
>
> import java.sql.Date;
> import java.util.TimeZone;
> public class DateProblem {
> public static void main(String[] a) {
> System.out.println(System.getProperty("java.runtime.version"));
> System.out.println(System.getProperty("os.name"));
> String[] ids = TimeZone.getAvailableIDs();
> for (int i = 0; i < ids.length; i++) {
> TimeZone.setDefault(TimeZone.getTimeZone(ids[i]));
> for (int y = 2037; y < 2039; y++) {
> for (int m = 101; m < 113; m++) {
> for (int d = 101; d < 129; d++) {
> test(y, m, d);
> }
> }
> }
> }
> }
> static void test(int y, int m, int d) {
> String s = y + "-" + ("" + m).substring(1) + "-" + ("" +
> d).substring(1);
> String s2 = Date.valueOf(s).toString();
> if (!s.equals(s2)) {
> String e = "java.sql.Date.valueOf(\"" + s + "\"): \"" + s2 + "\"";
> e += " TimeZone: " + TimeZone.getDefault().getID();
> System.out.println(e);
> }
> }
> }
>
> I get:
> 1.6.0_05-b13
> Windows XP
> java.sql.Date.valueOf("2038-03-14"): "2038-03-13" TimeZone: America/Havana
> java.sql.Date.valueOf("2038-03-14"): "2038-03-13" TimeZone: Cuba
> java.sql.Date.valueOf("2038-10-17"): "2038-10-16" TimeZone: America/Asuncion
> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Campo_Grande
> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Cuiaba
> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Santiago
> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: Antarctica/Palmer
> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: Chile/Continental
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: AGT
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> America/Argentina/Buenos_Aires
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> America/Argentina/Catamarca
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> America/Argentina/ComodRivadavia
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> America/Argentina/Cordoba
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> America/Argentina/Jujuy
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> America/Argentina/La_Rioja
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> America/Argentina/Mendoza
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> America/Argentina/Rio_Gallegos
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> America/Argentina/San_Juan
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> America/Argentina/Tucuman
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
> America/Argentina/Ushuaia
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Buenos_Aires
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Catamarca
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Cordoba
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Jujuy
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Mendoza
> java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Rosario
> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Sao_Paulo
> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: BET
> java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: Brazil/East
> java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone: America/Scoresbysund
> java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone: Atlantic/Azores
> java.sql.Date.valueOf("2038-03-25"): "2038-03-24" TimeZone: Asia/Amman
> java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone: Asia/Beirut
> java.sql.Date.valueOf("2038-03-26"): "2038-03-25" TimeZone: Asia/Damascus
> java.sql.Date.valueOf("2038-04-01"): "2038-03-31" TimeZone: Asia/Gaza
> java.sql.Date.valueOf("2038-03-21"): "2038-03-20" TimeZone: Asia/Tehran
> java.sql.Date.valueOf("2038-03-21"): "2038-03-20" TimeZone: Iran
>
> Regards,
> Thomas
>
--
Dag H. Wanvik, staff engineer
Sun Microsystems, Databases (JavaDB/Derby)
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax: +47 73842101
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
I just made a simple test case. Could you please run that and post the result?
import java.sql.Date;
import java.util.TimeZone;
public class DateProblem {
public static void main(String[] a) {
System.out.println(System.getProperty("java.runtime.version"));
System.out.println(System.getProperty("os.name"));
String[] ids = TimeZone.getAvailableIDs();
for (int i = 0; i < ids.length; i++) {
TimeZone.setDefault(TimeZone.getTimeZone(ids[i]));
for (int y = 2037; y < 2039; y++) {
for (int m = 101; m < 113; m++) {
for (int d = 101; d < 129; d++) {
test(y, m, d);
}
}
}
}
}
static void test(int y, int m, int d) {
String s = y + "-" + ("" + m).substring(1) + "-" + ("" +
d).substring(1);
String s2 = Date.valueOf(s).toString();
if (!s.equals(s2)) {
String e = "java.sql.Date.valueOf(\"" + s + "\"): \"" + s2 + "\"";
e += " TimeZone: " + TimeZone.getDefault().getID();
System.out.println(e);
}
}
}
I get:
1.6.0_05-b13
Windows XP
java.sql.Date.valueOf("2038-03-14"): "2038-03-13" TimeZone: America/Havana
java.sql.Date.valueOf("2038-03-14"): "2038-03-13" TimeZone: Cuba
java.sql.Date.valueOf("2038-10-17"): "2038-10-16" TimeZone: America/Asuncion
java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Campo_Grande
java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Cuiaba
java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Santiago
java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: Antarctica/Palmer
java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: Chile/Continental
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: AGT
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
America/Argentina/Buenos_Aires
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
America/Argentina/Catamarca
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
America/Argentina/ComodRivadavia
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
America/Argentina/Cordoba
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
America/Argentina/Jujuy
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
America/Argentina/La_Rioja
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
America/Argentina/Mendoza
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
America/Argentina/Rio_Gallegos
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
America/Argentina/San_Juan
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
America/Argentina/Tucuman
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone:
America/Argentina/Ushuaia
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Buenos_Aires
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Catamarca
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Cordoba
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Jujuy
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Mendoza
java.sql.Date.valueOf("2038-10-03"): "2038-10-02" TimeZone: America/Rosario
java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: America/Sao_Paulo
java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: BET
java.sql.Date.valueOf("2038-10-10"): "2038-10-09" TimeZone: Brazil/East
java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone: America/Scoresbysund
java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone: Atlantic/Azores
java.sql.Date.valueOf("2038-03-25"): "2038-03-24" TimeZone: Asia/Amman
java.sql.Date.valueOf("2038-03-28"): "2038-03-27" TimeZone: Asia/Beirut
java.sql.Date.valueOf("2038-03-26"): "2038-03-25" TimeZone: Asia/Damascus
java.sql.Date.valueOf("2038-04-01"): "2038-03-31" TimeZone: Asia/Gaza
java.sql.Date.valueOf("2038-03-21"): "2038-03-20" TimeZone: Asia/Tehran
java.sql.Date.valueOf("2038-03-21"): "2038-03-20" TimeZone: Iran
Regards,
Thomas
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> Bernt M. Johnsen wrote (2008-10-31 15:45:18):
> Although I can't shed any light on the Java/JavaDB problem, I can
> clarify a bit on DST and Brazil. Brazil decided by law 2008-09-08 that
> at 00:00 the third Sunday in October (which is 2008-10-18) is the
> change from DST to normal time and at 00:00 the third Sunday of
> February they will change back to DST. If your JDK is older than
> 2008-09-08, is is likely that it won't do this correct.
Forgot to mention, that if the third Sunday of February coincides with
the Carnival, DST change is postponed one week ;-)
>
> And, in 2042, the change will be on 2042-10-19 according to the new
> law.
>
>
> >>>>>>>>>>>> Mark Thornton wrote (2008-10-31 14:31:18):
> > Thomas Mueller wrote:
> >> What I plan to do in my database engine is to set the time to 12:00:00
> >> (midday). Unfortunately this breaks a few things, like equality of
> >> java.sql.Date that are returned by H2 and dates that are created by
> >> java.sql.Date.valueOf, but I don't know how to solve the problem
> >> otherwise (short term). Long term, an option might be to fix the
> >> problem in java.sql.Date.
> >>
> >
> > The long term solution is probably jsr310 which replaces all the
> > date/time classes with something more rational.
> >
> > Mark Thornton
>
> --
> Bernt Marius Johnsen, Staff Engineer
> Database Technology Group, Sun Microsystems, Trondheim, Norway
--
Bernt Marius Johnsen, Staff Engineer
Database Technology Group, Sun Microsystems, Trondheim, Norway
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
Although I can't shed any light on the Java/JavaDB problem, I can
clarify a bit on DST and Brazil. Brazil decided by law 2008-09-08 that
at 00:00 the third Sunday in October (which is 2008-10-18) is the
change from DST to normal time and at 00:00 the third Sunday of
February they will change back to DST. If your JDK is older than
2008-09-08, is is likely that it won't do this correct.
And, in 2042, the change will be on 2042-10-19 according to the new
law.
>>>>>>>>>>>> Mark Thornton wrote (2008-10-31 14:31:18):
> Thomas Mueller wrote:
>> What I plan to do in my database engine is to set the time to 12:00:00
>> (midday). Unfortunately this breaks a few things, like equality of
>> java.sql.Date that are returned by H2 and dates that are created by
>> java.sql.Date.valueOf, but I don't know how to solve the problem
>> otherwise (short term). Long term, an option might be to fix the
>> problem in java.sql.Date.
>>
>
> The long term solution is probably jsr310 which replaces all the
> date/time classes with something more rational.
>
> Mark Thornton
--
Bernt Marius Johnsen, Staff Engineer
Database Technology Group, Sun Microsystems, Trondheim, Norway
Re: Date 2042-10-12 problem using Brasilia time zone
Posted by Mark Thornton <mt...@optrak.co.uk>.
Thomas Mueller wrote:
> What I plan to do in my database engine is to set the time to 12:00:00
> (midday). Unfortunately this breaks a few things, like equality of
> java.sql.Date that are returned by H2 and dates that are created by
> java.sql.Date.valueOf, but I don't know how to solve the problem
> otherwise (short term). Long term, an option might be to fix the
> problem in java.sql.Date.
>
The long term solution is probably jsr310 which replaces all the
date/time classes with something more rational.
Mark Thornton