Likes Likes:  0
Resultaten 1 tot 2 van de 2
Geen
  1. #1
    Peter Conrad
    Oracle JDBC: Inconsistent handling of timestamps
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Oracle JDBC: Inconsistent handling of timestamps

    Product: Oracle database 8.1.7 & JDBC "thin" driver 8.1.7.1
    Issue: Inconsistent handling of timestamps
    Impact: Minor (as a security issue, what comes to mind is bad timestamps
    when logging to an Oracle DB)
    Could be a major problem for any application relying on certain
    timestamp properties, though.
    History: Posted to Oracle JDBC web forum on October 28th - no vendor response
    (see http://www.oracle.com/forums/message...122&gid=390686 )
    Sent email to secalert_us@oracle.com on December 3rd
    - vendor acknowledged receipt on Dec 4
    Requested status from secalert_us@oracle.com on Feb 18 and Mar 17
    - no response so far


    Description:

    Certain java.sql.Timestamp values aren't written to (or retrieved from)
    the database correctly. Timestamps affected are in the time interval just
    before switchover from DST to non-DST (the bug was noticed on
    October 27th 2002 for the first time, when the switchover from MET/DST to MET
    took place). Various timestamp values in the range
    2:00 AM - 2:59:59 AM (MET/DST) on October 27th 2002 as well as on October
    26th 2003 have been verified to reproduce the bug, with the database as
    well as the JDBC client running in MET.

    What happens is this:

    - We insert a new row into table T, column C , giving it timestamp X, like
    INSERT INTO T (C) VALUES (X)

    - Later, we try to retrieve the row using
    ResultSet = SELECT C FROM T WHERE C = X

    - We find that ResultSet.C <> X!
    (More precisely: ResultSet.C = X + 1 hour)


    Example code:

    The following code snippet can be used to reproduce the bug in the MET
    timezone. The "problem" timestamp probably has to be adjusted for other
    timezones.


    Connection c = DriverManager.getConnection(DB_URL, DB_USER, DB_PWD);
    PreparedStatement p = c.prepareStatement("CREATE TABLE BugTest (ts DATE NOT NULL)");
    p.execute();
    p.close();

    Timestamp problem = new Timestamp(1067130000000L); // 26.10.03 02:00 MET/DST

    p = c.prepareStatement("INSERT INTO BugTest (ts) VALUES (?)");
    p.setTimestamp(1, problem);
    p.execute();
    p.close();

    p = c.prepareStatement("SELECT * FROM BugTest WHERE ts = ?");
    p.setTimestamp(1, problem);
    ResultSet rs = p.executeQuery();
    if (rs.next()) {
    Timestamp ts = rs.getTimestamp(1);
    if (ts.equals(problem)) {
    System.out.println("Everything's OK");
    } else {
    System.out.println("Gotcha! DB returns " + ts.getTime()
    + " but we gave it "
    + problem.getTime()
    + "!");
    }
    }
    p = c.prepareStatement("DROP TABLE BugTest");
    p.execute();
    p.close();
    c.close();

    --
    Peter Conrad Tel: +49 6102 / 80 99 072
    [ t]ivano Software GmbH Fax: +49 6102 / 80 99 071
    Bahnhofstr. 18
    63263 Neu-Isenburg

    Germany

  2. #2
    Peter J. Holzer
    Oracle JDBC: Inconsistent handling of timestamps
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Oracle JDBC: Inconsistent handling of timestamps

    --2B/JsCI69OhZNC5r
    Content-Type: text/plain; charset=iso-8859-1
    Content-Disposition: inline
    Content-Transfer-Encoding: quoted-printable

    On 2003-03-31 10:48:05 +0200, Peter Conrad wrote:
    > Certain java.sql.Timestamp values aren't written to (or retrieved from)
    > the database correctly. Timestamps affected are in the time interval just
    > before switchover from DST to non-DST (the bug was noticed on=20
    > October 27th 2002 for the first time, when the switchover from MET/DST to=

    MET
    > took place). Various timestamp values in the range
    > 2:00 AM - 2:59:59 AM (MET/DST) on October 27th 2002 as well as on October
    > 26th 2003 have been verified to reproduce the bug, with the database as
    > well as the JDBC client running in MET.

    [...]
    > Timestamp problem =3D new Timestamp(1067130000000L); // 26.10.03 02:0=

    0 MET/DST

    That's a general problem with daylight savings time. On the switch from
    DST to standard time, one hour (02:00:00 .. 03:00:00 in the case of MET)
    occurs twice. If a timestamp is stored in the local timezone but without
    timezone information, this information is ambiguous.=20

    This is not Oracle-specific but would happen with any database which
    stores timestamps in "human readable" form without timezone information.

    If you need to store unambiguous timestamps, use UTC or a numeric=20
    "units since the epoch" format (like POSIX time_t or Java millis).

    What's nasty about your sample code is that you specify the timestamp in
    Java millis, but it isn't stored that way. It is easy for a programmer
    to forget about the type conversion and possible loss of information.

    hp

    --=20
    _ | Peter J. Holzer | Unser Universum w=E4re betr=FCblich
    |_|_) | Sysadmin WSR / LUGA | unbedeutend, h=E4tte es nicht jeder
    | | | hjp@wsr.ac.at | Generation neue Probleme bereit.
    __/ | http://www.hjp.at/ | -- Seneca, naturales quaestiones

    --2B/JsCI69OhZNC5r
    Content-Type: application/pgp-signature
    Content-Disposition: inline

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.0.6 (GNU/Linux)
    Comment: For info see http://www.gnupg.org

    iQDQAwUBPoqqqlLjemazOuKpAQEqGgXRATcsvnvOaFx0VNOCfK WSJevGPcd8zcpC
    TN/hmvPcJ34av0mfWgTINj3dJuX9QMHJewz7K90e/xHCoU6pDZ5tID8oUbZvvjlB
    lyVs0Wnx1Q2XAKivrxRRZBpHQBRQle6fQbRLcLs8V1hV+SZqUR dEMaogkN9BhKCD
    qtj38aAAC0JulVSbjCdX41uKujNlv+MMeUMu/2PZXnOl4Rg7TVlwVTCRHsKqmzul
    mGL0lv7WKHasEYzAEREBzs5lBA==
    =R1lc
    -----END PGP SIGNATURE-----

    --2B/JsCI69OhZNC5r--

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics