Thread: [BUG?] Extreme dates

[BUG?] Extreme dates

From
ow
Date:
Hi,

> I've tried to duplicate this and have failed.  It does appear that Java is
> doing something strange with the date, changing it to 11/30/0002,

Probably because months start with 0.

> Please try the attached test and see what changes are necessary to get the
> failure you describe.

The following test illustrates the issue.  The output I get is:

Row number= 0 col 1= 2030-02-11 14:06:00.828 col 2=2004-05-17 14:06:00.828


    public void testKillMe() throws Exception {
//--------------- cut here
        Class.forName("org.postgresql.Driver");
        Connection conn =
DriverManager.getConnection("jdbc:postgresql://localhost:5432/rc","testuser","");

        Statement stmt = conn.createStatement();
        stmt.executeUpdate("CREATE TEMP TABLE tt (aMin timestamp, aMax timestamp)");
        stmt.close();

        Calendar cal = Calendar.getInstance();
        cal.set(2, 10, 30);
//        cal.set(0, 0, 0);
        java.sql.Date d = new java.sql.Date(cal.getTimeInMillis());
        System.out.println("Inserting: " + d);

        PreparedStatement pstmt = conn.prepareStatement("INSERT INTO tt VALUES (?,
?)");
        pstmt.setTimestamp(1, new java.sql.Timestamp(d.getTime()));
        pstmt.setTimestamp(2, new java.sql.Timestamp(System.currentTimeMillis()));
        pstmt.executeUpdate();
        pstmt.close();

        stmt = conn.createStatement();
        ResultSet rs = stmt.executeQuery("SELECT * FROM tt");
        int i = 0;
        while (rs.next()) {
            System.out.println("Row number = " + i + " col 1= " + rs.getTimestamp(1) + "
col 2=" + rs.getTimestamp(2));
            i++;
        }
//--------------- cut here
    }


Thanks








__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/

Re: [BUG?] Extreme dates

From
Kris Jurka
Date:

On Mon, 17 May 2004, ow wrote:

> [timestamps like 0002-10-30 are incorrectly seen as 2030-02-10].

Yes, that's a bug alright.  I've fixed this in both the stable and
development cvs trees.  While looking at this I noticed that the timestamp
code has no provisions for BC dates, so if you're working with years in
that area, that's something to be aware of.  Fixing that has gone on the
todo list, but I wanted to get this fix out to you now.

Kris Jurka


Re: [BUG?] Extreme dates

From
ow
Date:
--- Kris Jurka <books@ejurka.com> wrote:
>
> [timestamps like 0002-10-30 are incorrectly seen as 2030-02-10].
...
>  Fixing that has gone on the todo list, but I wanted to get this fix out to
>  you now.

Is it going to be a new build posted to the website or should I get it from
CVS?

Thanks!








__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/

Re: [BUG?] Extreme dates

From
Kris Jurka
Date:

On Mon, 17 May 2004, ow wrote:

>
> --- Kris Jurka <books@ejurka.com> wrote:
> >
> > [timestamps like 0002-10-30 are incorrectly seen as 2030-02-10].
> ...
> >  Fixing that has gone on the todo list, but I wanted to get this fix out to
> >  you now.
>
> Is it going to be a new build posted to the website or should I get it from
> CVS?
>

I don't have access to the jdbc website, currently only Dave or Barry can
post new builds.  I will usually post new builds to
http://www.ejurka.com/pgsql/jars every so often because the main website
doesn't get much in the way of updates.  This isn't ideal for a number of
reasons:

1) The public website should be up to date.

2) No one knows about http://www.ejurka.com/pgsql/jars

3) I don't bump the official build number when putting up these
intermediate builds so people can have jar files with the same build
number and different code.

I'll start bothering people again about letting me update the website...

Kris Jurka

Re: [BUG?] Extreme dates

From
ow
Date:
--- Kris Jurka <books@ejurka.com> wrote:
> I don't have access to the jdbc website, currently only Dave or Barry can
> post new builds.  I will usually post new builds to
> http://www.ejurka.com/pgsql/jars every so often because the main website
> doesn't get much in the way of updates.

Hi,

I tried the jar, it appears that *occasionally* it saves null date as
0002-12-31 (not 100% sure about that, maybe an app error). It also appears
there're some debugging printlns inside.

Anyway, thanks!








__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/

Re: [BUG?] Extreme dates

From
Kris Jurka
Date:

On Tue, 18 May 2004, ow wrote:

>
> --- Kris Jurka <books@ejurka.com> wrote:
> > I don't have access to the jdbc website, currently only Dave or Barry can
> > post new builds.  I will usually post new builds to
> > http://www.ejurka.com/pgsql/jars every so often because the main website
> > doesn't get much in the way of updates.
>
> Hi,
>
> I tried the jar, it appears that *occasionally* it saves null date as
> 0002-12-31 (not 100% sure about that, maybe an app error). It also appears
> there're some debugging printlns inside.
>

Please recheck your own code for both of these problems.  I don't believe
the driver is doing either of these.

Kris Jurka

Re: [BUG?] Extreme dates

From
Markus Schaber
Date:
Hi, Kris,

On Mon, 17 May 2004 15:45:12 -0500 (EST)
Kris Jurka <books@ejurka.com> wrote:

> > [timestamps like 0002-10-30 are incorrectly seen as 2030-02-10].
>
> Yes, that's a bug alright.  I've fixed this in both the stable and
> development cvs trees.  While looking at this I noticed that the
> timestamp code has no provisions for BC dates, so if you're working
> with years in that area, that's something to be aware of.  Fixing that
> has gone on the todo list, but I wanted to get this fix out to you
> now.

I just notified the change in the JDBC CVS, and have a (very small)
remark:

sbuf.append("0") is less efficient than sbuf.append('0').

The first reason is that for storing "0", there is a String object
created by the jvm, with an associated internal char[] array, which is
bound to the Class instance, while '0' as a constant scalar character is
no extra object.

And the second reason is that, as the StringBuffer source shows, adding
a String to a StringBuffer is much more work including a call to
System.ArrayCopy, while adding a simple character is just ensuring the
capacity and putting it in.

Interestingly, the lines below your insertion, already use chars, while
a little bit above, there's another example adding a single-byte String
(maybe because of lazyness to quote a ' inside of '').

So if you feel like peephole-optimizing, you can apply the attached
patch, if not, don't mind.

Thanks for your patience,
Markus Schaber
--
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios@logi-track.com | www.logi-track.com


Attachment

Re: [BUG?] Extreme dates

From
ow
Date:
--- Kris Jurka <books@ejurka.com> wrote:
> > Hi,
> >
> > I tried the jar, it appears that *occasionally* it saves null date as
> > 0002-12-31 (not 100% sure about that, maybe an app error). It also appears
> > there're some debugging printlns inside.
> >
>
> Please recheck your own code for both of these problems.  I don't believe
> the driver is doing either of these.
>
> Kris Jurka

I think you're right. Must've been an app error. Thanks








__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/