Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Re: Patch for JDBC timestamp problems

From: Joseph Shraibman <jks(at)selectacast(dot)net>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Barry Lind <barry(at)xythos(dot)com>, pgsql-patches(at)postgresql(dot)org, pgsql-interfaces(at)postgresql(dot)org, PostgreSQL jdbc list <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: [PATCHES] Re: Patch for JDBC timestamp problems
Date: 2001-01-24 21:56:54
Message-ID: 3A6F4FA6.38864C90@selectacast.net (view raw or flat)
Thread:
Lists: pgsql-interfacespgsql-jdbcpgsql-patches
No, it cannot be static.

Bruce Momjian wrote:
> 
> What was the conclusion of this discussion?  Do we leave it static?
> 
> > Barry Lind wrote:
> > >
> > > Attached is a set of patches for a couple of bugs dealing with
> > > timestamps in JDBC.
> > >
> > > Bug#1) Incorrect timestamp stored in DB if client timezone different
> > > than DB.
> > >
> > > The buggy implementation of setTimestamp() in PreparedStatement simply
> > > used the toString() method of the java.sql.Timestamp object to convert
> > > to a string to send to the database.  The format of this is yyyy-MM-dd
> > > hh:mm:ss.SSS which doesn't include any timezone information.  Therefore
> > > the DB assumes its timezone since none is specified.  That is OK if the
> > > timezone of the client and server are the same, however if they are
> > > different the wrong timestamp is received by the server.  For example if
> > > the client is running in timezone GMT and wants to send the timestamp
> > > for noon to a server running in PST (GMT-8 hours), then the server will
> > > receive 2000-01-12 12:00:00.0 and interprete it as 2000-01-12
> > > 12:00:00-08 which is 2000-01-12 04:00:00 in GMT.  The fix is to send a
> > > format to the server that includes the timezone offset.  For simplicity
> > > sake the fix uses a SimpleDateFormat object with its timezone set to GMT
> > > so that '+00' can be used as the timezone for postgresql.  This is done
> > > as SimpleDateFormat doesn't support formating timezones in the way
> > > postgresql expects.
> > >
> > > Bug#2) Incorrect handling of partial seconds in getting timestamps from
> > > the DB
> > >
> > > When the SimpleDateFormat object parses a string with a format like
> > > yyyy-MM-dd hh:mm:ss.SS it expects the fractional seconds to be three
> > > decimal places (time precision in java is miliseconds = three decimal
> > > places).  This seems like a bug in java to me, but it is unlikely to be
> > > fixed anytime soon, so the postgresql code needed modification to
> > > support the java behaviour.  So for example a string of '2000-01-12
> > > 12:00:00.12-08' coming from the database was being converted to a
> > > timestamp object with a value of 2000-01-12 12:00:00.012GMT-08:00.  The
> > > fix was to check for a '.' in the string and if one is found append on
> > > an extra zero to the fractional seconds part.
> > >
> > > Bug#3) Performance problems
> > >
> > > In fixing the above two bugs, I noticed some things that could be
> > > improved.  In PreparedStatement.setTimestamp(),
> > > PreparedStatement.setDate(), ResultSet.getTimestamp(), and
> > > ResultSet.getDate() these methods were creating a new SimpleDateFormat
> > > object everytime they were called.  To avoid this unnecessary object
> > > creation overhead, I changed the code to use static variables for
> > > keeping a single instance of the needed formating objects.
> > > Also the code used the + operator for string concatenation.  As everyone
> > > should know this is very inefficient and the use of StringBuffers is
> > > prefered.
> > >
> >
> > While the java spec says that a+b+c should be converted into
> > a.concat(b.toString()).concat(c.toString())
> >  probably every single java compiler (including javac) uses
> > StringBuffers.  The only case where it is an advantage to use your own
> > stringBuffer is in a case like:
> >
> > StringBuffer sb = new StringBuffer("blah");
> > sb.append(a+b+c);
> >
> > Since that would create a temporary StringBuffer to calculate a+b+c just
> > to append to the original sb it it might be better to explictly append
> > a,b,and c.
> >
> >
> > Using static SimpleDateFormats will probably not cause threading
> > issues.  Common sense says that if the set methods are never called on
> > them there will be no state change that my cause sync problems.  But the
> > spec doesn't garuntee it.  Personally I would have no problem using
> > static SimpleDateFormats if this were my code.
> >
> >
> >
> > --
> > Joseph Shraibman
> > jks(at)selectacast(dot)net
> > Increase signal to noise ratio.  http://www.targabot.com
> >
> 
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

-- 
Joseph Shraibman
jks(at)selectacast(dot)net
Increase signal to noise ratio.  http://www.targabot.com

In response to

Responses

pgsql-patches by date

Next:From: Joseph ShraibmanDate: 2001-01-24 22:25:44
Subject: Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems
Previous:From: Barry LindDate: 2001-01-24 21:27:34
Subject: PATCH for arrayindexoutofbounds exception in latest code

pgsql-interfaces by date

Next:From: Poul KristensenDate: 2001-01-24 21:58:33
Subject: Sv: Postgres ODBC
Previous:From: Robert A. Knop Jr.Date: 2001-01-24 21:10:07
Subject: PQftype, Oid, where is this documented?

pgsql-jdbc by date

Next:From: The Hermit HackerDate: 2001-01-24 22:22:07
Subject: Re: Re: [GENERAL] Re: JDBC Performance
Previous:From: Paul M. AokiDate: 2001-01-24 21:42:43
Subject: Re: no way in LargeObject API to detect short read?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group