agora inbox for pljava-dev@postgresql.org  
help / color / mirror / Atom feed
[Pljava-dev] R:  select CURRENT_TIMESTAMP is wrong
5+ messages / 0 participants
[nested] [flat]

* [Pljava-dev] R:  select CURRENT_TIMESTAMP is wrong
@ 2008-01-23 12:59  
  0 siblings, 1 reply; 5+ messages in thread

From:  @ 2008-01-23 12:59 UTC (permalink / raw)

Thanks for replay.

But notings change.

INFO:  23 Jan 08 13:57:39 xxx.HelloWorld Time is Wed Jan 23 13:57:39 CET
2008
INFO:  23 Jan 08 13:57:39 xxx.HelloWorld Sql Time is :1978-02-13
07:44:13.000318

Logger.getAnonymousLogger().info( "Sql Time is
:"+rs.getTimestamp(1).toString()+"\n");




-----Messaggio originale-----
Da: pljava-dev-bounces at pgfoundry.org
[mailto:pljava-dev-bounces at pgfoundry.org] Per conto di Jeffrey Lyon
Inviato: mercoled? 23 gennaio 2008 13.47
A: pljava-dev at pgfoundry.org
Oggetto: Re: [Pljava-dev] select CURRENT_TIMESTAMP is wrong

What happens if, instead of rs.getString(1), you retrieve the  
Timestamp via an rs.getTimestamp(1).toString()?

J

On Jan 23, 2008, at 7:34 AM, Stefano Bianchi wrote:

> Hi,
>
> I have a PostgreSQL 8.1.10 on i486-pc-linux-gnu, compiled by GCC cc  
> (GCC)
> 4.2.1 (Debian 4.2.1-5), with pljava-i686-pc-linux-gnu- 
> pg8.1-1.3.0.tar.gz
> installed.
>
> I try to use CURRENT_TIMESTAMP (now()) from database with this simple
> function:
>
> package net.iskranet.java.pljava.test;
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import java.util.logging.Logger;
> import java.util.Date;
>
>
> public class HelloWorld {
> 	private static java.lang.String m_url = "jdbc:default:connection";
>
> 	public static String helloWorld() throws SQLException {
> 		String query="select current_timestamp";
> 		
> 		Logger.getAnonymousLogger().info( "Time is " + new
> Date(System.currentTimeMillis())+"\n");
>
> 		Connection conn = DriverManager.getConnection(m_url);
> 		Statement stmt = conn.createStatement();
> 		ResultSet rs = stmt.executeQuery(query);
> 		conn.close();
> 		
> 		rs.next();
> 		Logger.getAnonymousLogger().info( "Sql Time is
> :"+rs.getString(1)+"\n");
> 		return "Hello World";
> 	}
> }
>
> BUT my result are:
> INFO:  xxx HelloWorld Time is Wed Jan 23 12:32:31 CET 2008
> INFO:  xxx HelloWorld Sql Time is :1978-02-13 06:19:06.000088
>
> I read on news pljava should adapt itself on different postgresql
> installation, but may I have do somethings wrong, because it don't  
> work
>
> Can anyone help me ?
> Thanks in advance
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/pljava-dev

_______________________________________________
Pljava-dev mailing list
Pljava-dev at pgfoundry.org
http://pgfoundry.org/mailman/listinfo/pljava-dev





^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* [Pljava-dev] R:  select CURRENT_TIMESTAMP is wrong
@ 2008-01-23 13:18  
  parent: 
  0 siblings, 1 reply; 5+ messages in thread

From:  @ 2008-01-23 13:18 UTC (permalink / raw)

That is strange - I did this on Java 5/OS X 10.5.1/Pgsql 8.1.3:

	ResultSet time = connection.executeQuery("SELECT now();");
	time.next();
	System.err.println(time.getString(1));
	System.err.println(time.getTimestamp(1).toString());


... and got this result:

2008-01-23 08:14:30.740862-05
2008-01-23 08:14:30.740862

What if you don't close the Connection until you retrieve the results  
of the ResultSet?

J

On Jan 23, 2008, at 7:59 AM, Stefano Bianchi wrote:

> Thanks for replay.
>
> But notings change.
>
> INFO:  23 Jan 08 13:57:39 xxx.HelloWorld Time is Wed Jan 23 13:57:39  
> CET
> 2008
> INFO:  23 Jan 08 13:57:39 xxx.HelloWorld Sql Time is :1978-02-13
> 07:44:13.000318
>
> Logger.getAnonymousLogger().info( "Sql Time is
> :"+rs.getTimestamp(1).toString()+"\n");
>
>
>
>
> -----Messaggio originale-----
> Da: pljava-dev-bounces at pgfoundry.org
> [mailto:pljava-dev-bounces at pgfoundry.org] Per conto di Jeffrey Lyon
> Inviato: mercoled? 23 gennaio 2008 13.47
> A: pljava-dev at pgfoundry.org
> Oggetto: Re: [Pljava-dev] select CURRENT_TIMESTAMP is wrong
>
> What happens if, instead of rs.getString(1), you retrieve the
> Timestamp via an rs.getTimestamp(1).toString()?
>
> J
>
> On Jan 23, 2008, at 7:34 AM, Stefano Bianchi wrote:
>
>> Hi,
>>
>> I have a PostgreSQL 8.1.10 on i486-pc-linux-gnu, compiled by GCC cc
>> (GCC)
>> 4.2.1 (Debian 4.2.1-5), with pljava-i686-pc-linux-gnu-
>> pg8.1-1.3.0.tar.gz
>> installed.
>>
>> I try to use CURRENT_TIMESTAMP (now()) from database with this simple
>> function:
>>
>> package net.iskranet.java.pljava.test;
>> import java.sql.Connection;
>> import java.sql.DriverManager;
>> import java.sql.ResultSet;
>> import java.sql.SQLException;
>> import java.sql.Statement;
>> import java.util.logging.Logger;
>> import java.util.Date;
>>
>>
>> public class HelloWorld {
>> 	private static java.lang.String m_url = "jdbc:default:connection";
>>
>> 	public static String helloWorld() throws SQLException {
>> 		String query="select current_timestamp";
>> 		
>> 		Logger.getAnonymousLogger().info( "Time is " + new
>> Date(System.currentTimeMillis())+"\n");
>>
>> 		Connection conn = DriverManager.getConnection(m_url);
>> 		Statement stmt = conn.createStatement();
>> 		ResultSet rs = stmt.executeQuery(query);
>> 		conn.close();
>> 		
>> 		rs.next();
>> 		Logger.getAnonymousLogger().info( "Sql Time is
>> :"+rs.getString(1)+"\n");
>> 		return "Hello World";
>> 	}
>> }
>>
>> BUT my result are:
>> INFO:  xxx HelloWorld Time is Wed Jan 23 12:32:31 CET 2008
>> INFO:  xxx HelloWorld Sql Time is :1978-02-13 06:19:06.000088
>>
>> I read on news pljava should adapt itself on different postgresql
>> installation, but may I have do somethings wrong, because it don't
>> work
>>
>> Can anyone help me ?
>> Thanks in advance
>>
>> _______________________________________________
>> Pljava-dev mailing list
>> Pljava-dev at pgfoundry.org
>> http://pgfoundry.org/mailman/listinfo/pljava-dev
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/pljava-dev
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/pljava-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20080123/ce839f4d/attachment.html;



^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* [Pljava-dev] R:  select CURRENT_TIMESTAMP is wrong
@ 2008-01-25 09:14  
  parent: 
  0 siblings, 1 reply; 5+ messages in thread

From:  @ 2008-01-25 09:14 UTC (permalink / raw)

I didn't post this to the list by mistake, but I found a solution. It  
appears that some precision is being lost with certain compilers. The  
culprit is this:
         mSecs += EPOCH_DIFF * 1000;                     /* Adjust for  
diff between Postgres and Java (Unix) */

EPOCH_DIFF is cast as an int32; multiplying it by 1000 yields some 949  
billion. Here's a fix:

--- src/C/pljava/type/Timestamp.c	12 Sep 2007 17:59:43 -0000	1.19
+++ src/C/pljava/type/Timestamp.c	25 Jan 2008 09:04:44 -0000
@@ -14,7 +14,7 @@
  #include "pljava/type/Type_priv.h"
  #include "pljava/type/Timestamp.h"

-#define EPOCH_DIFF (((uint32)86400) * (POSTGRES_EPOCH_JDATE -  
UNIX_EPOCH_JDATE))
+#define EPOCH_DIFF (((uint64)86400) * (POSTGRES_EPOCH_JDATE -  
UNIX_EPOCH_JDATE))

  /*
   * Timestamp type. Postgres will pass (and expect in return) a local  
timestamp.


- Lucas Madar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20080125/489b21e7/attachment.html;



^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* [Pljava-dev] R:  select CURRENT_TIMESTAMP is wrong
@ 2008-01-25 10:08  
  parent: 
  0 siblings, 1 reply; 5+ messages in thread

From:  @ 2008-01-25 10:08 UTC (permalink / raw)



On Fri, 25 Jan 2008, Lucas Madar wrote:

> I didn't post this to the list by mistake, but I found a solution. It appears 
> that some precision is being lost with certain compilers. The culprit is 
> this:
>       mSecs += EPOCH_DIFF * 1000;                     /* Adjust for diff 
> between Postgres and Java (Unix) */
>
> EPOCH_DIFF is cast as an int32; multiplying it by 1000 yields some 949 
> billion. Here's a fix:
>
> +#define EPOCH_DIFF (((uint64)86400) * (POSTGRES_EPOCH_JDATE - 
> UNIX_EPOCH_JDATE))
>

I'm not sure what the implications of this change are.  I see this 
existing code for the reverse operation and think we should mirror that 
instead:

src/C/pljava/type/Timestamp.c:97

         mSecs -= ((jlong)EPOCH_DIFF) * 1000L;

Kris Jurka

PS: I'm aware of your other reports, but I just haven't found the time to 
look into them.  Keep things coming and we'll get to them eventually.




^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* [Pljava-dev] R:  select CURRENT_TIMESTAMP is wrong
@ 2008-02-01 05:09  
  parent: 
  0 siblings, 0 replies; 5+ messages in thread

From:  @ 2008-02-01 05:09 UTC (permalink / raw)



On Fri, 25 Jan 2008, Kris Jurka wrote:

> On Fri, 25 Jan 2008, Lucas Madar wrote:
>
>> I didn't post this to the list by mistake, but I found a solution. It appears
>> that some precision is being lost with certain compilers. The culprit is
>> this:
>>       mSecs += EPOCH_DIFF * 1000;                     /* Adjust for diff
>> between Postgres and Java (Unix) */
>>

This is not compiler dependent, it just depends on whether this code is 
used or not.  This function is only used when running against a server 
built with integer datetimes.

Fixed in CVS.

Kris Jurka




^ permalink  raw  reply  [nested|flat] 5+ messages in thread


end of thread, other threads:[~2008-02-01 05:09 UTC | newest]

Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2008-01-23 12:59 [Pljava-dev] R:  select CURRENT_TIMESTAMP is wrong 
2008-01-23 13:18 ` 
2008-01-25 09:14   ` 
2008-01-25 10:08     ` 
2008-02-01 05:09       ` 

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox