JDBC commit to 7.1.2

The jdbc1 code does not have the problem that this patch corrects. So
no it does not need to be and should not be applied to the jdbc1 area.

I also noticed that that the original patch which was for the
jdbc2/ResultSet.java file was also applied to the jdbc1/ResultSet.java
file on the main trunk of the CVS. This will not work and that patch
needs to be removed from jdbc1/ResultSet.java. (The variable the patch
uses doesn't exist in the jdbc1 code thus the current jdbc1 code will
not compile).

The jdbc1 and jdbc2 sets of files are sufficiently different that
patches for one should not be applied to the other.

thanks,
--Barry

Bruce Momjian wrote:

The jdbc1 code does not have the problem that this patch corrects. So
no it does not need to be and should not be applied to the jdbc1 area.

I also noticed that that the original patch which was for the
jdbc2/ResultSet.java file was also applied to the jdbc1/ResultSet.java
file on the main trunk of the CVS. This will not work and that patch
needs to be removed from jdbc1/ResultSet.java. (The variable the patch
uses doesn't exist in the jdbc1 code thus the current jdbc1 code will
not compile).

The jdbc1 and jdbc2 sets of files are sufficiently different that
patches for one should not be applied to the other.

Got it. Backed out of jdbc1 in current.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

FYI, the reason I personally didn't want to apply this to 7.1.2 is
because we already added two new bugs in 7.1.1, and I didn't want to be
the one to add another. Add that to the natural problems I have with
JDBC, and I ran. :-)

The jdbc1 code does not have the problem that this patch corrects. So
no it does not need to be and should not be applied to the jdbc1 area.

I also noticed that that the original patch which was for the
jdbc2/ResultSet.java file was also applied to the jdbc1/ResultSet.java
file on the main trunk of the CVS. This will not work and that patch
needs to be removed from jdbc1/ResultSet.java. (The variable the patch
uses doesn't exist in the jdbc1 code thus the current jdbc1 code will
not compile).

The jdbc1 and jdbc2 sets of files are sufficiently different that
patches for one should not be applied to the other.

thanks,
--Barry

Bruce Momjian wrote:

This timezone fix was applied to jdbc2 in 7.1.2 by Thomas. Do you want
this in jdbc1 also? I am not recommending it, just asking to make sure
it wasn't overlooked.

---------------------------------------------------------------------------

revision 1.22.2.1
date: 2001/05/22 14:46:46; author: thomas; state: Exp; lines: +4 -4
Patch from Barry Lind to correctly decode time zones in timestamp results.
Without patch, the time zone field is ignored and the returned time is
not correct.
Already applied to the development tree...

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

FYI, the reason I personally didn't want to apply this to 7.1.2 is
because we already added two new bugs in 7.1.1, and I didn't want to be
the one to add another. Add that to the natural problems I have with
JDBC, and I ran. :-)

Understandable. You shouldn't *have* to take responsibility for every
patch coming in, so feel free to leave some things for others. And if
there is a problem with this one, I'll understand if you need to yell at
me a little ;)

As a (sort of) aside, by forcing me to inspect the code we have
uncovered a problem with atypical time zones which we would not
otherwise have noticed, at least until someone in Newfoundland or India
stumbled on it. No patch yet, but at least we know it is there...

- Thomas

Attached is a patch to fix the problem Thomas mentions below. The JDBC
driver now correctly handles timezones that are offset fractional hours
from GMT (ie. -06:30).

thanks,
--Barry

Thomas Lockhart wrote:

Your patch has been added to the PostgreSQL unapplied patches list at:

http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it withing the next 48 hours.

Attached is a patch to fix the problem Thomas mentions below. The JDBC
driver now correctly handles timezones that are offset fractional hours
from GMT (ie. -06:30).

thanks,
--Barry

Thomas Lockhart wrote:

FYI, the reason I personally didn't want to apply this to 7.1.2 is
because we already added two new bugs in 7.1.1, and I didn't want to be
the one to add another. Add that to the natural problems I have with
JDBC, and I ran. :-)

Understandable. You shouldn't *have* to take responsibility for every
patch coming in, so feel free to leave some things for others. And if
there is a problem with this one, I'll understand if you need to yell at
me a little ;)

As a (sort of) aside, by forcing me to inspect the code we have
uncovered a problem with atypical time zones which we would not
otherwise have noticed, at least until someone in Newfoundland or India
stumbled on it. No patch yet, but at least we know it is there...

- Thomas

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

*** ./org/postgresql/jdbc1/ResultSet.java.orig	Fri May 25 16:23:19 2001
--- ./org/postgresql/jdbc1/ResultSet.java	Fri May 25 16:26:35 2001
***************
*** 472,484 ****
//so this code strips off timezone info and adds on the GMT+/-...
//as well as adds a third digit for partial seconds if necessary
StringBuffer strBuf = new StringBuffer(s);
char sub = strBuf.charAt(strBuf.length()-3);
if (sub == '+' || sub == '-') {
strBuf.setLength(strBuf.length()-3);
if (subsecond)  {
!         strBuf = strBuf.append('0').append("GMT").append(s.substring(s.length()-3, s.length())).append(":00");
} else {
!         strBuf = strBuf.append("GMT").append(s.substring(s.length()-3, s.length())).append(":00");
}
} else if (subsecond) {
strBuf = strBuf.append('0');
--- 472,506 ----
//so this code strips off timezone info and adds on the GMT+/-...
//as well as adds a third digit for partial seconds if necessary
StringBuffer strBuf = new StringBuffer(s);
+ 
+     //we are looking to see if the backend has appended on a timezone.
+     //currently postgresql will return +/-HH:MM or +/-HH for timezone offset
+     //(i.e. -06, or +06:30, note the expectation of the leading zero for the
+     //hours, and the use of the : for delimiter between hours and minutes)
+     //if the backend ISO format changes in the future this code will
+     //need to be changed as well
char sub = strBuf.charAt(strBuf.length()-3);
if (sub == '+' || sub == '-') {
strBuf.setLength(strBuf.length()-3);
if (subsecond)  {
!         strBuf.append('0').append("GMT").append(s.substring(s.length()-3, s.length())).append(":00");
!       } else {
!         strBuf.append("GMT").append(s.substring(s.length()-3, s.length())).append(":00");
!       }
!     } else if (sub == ':') {
!       //we may have found timezone info of format +/-HH:MM, or there is no
!       //timezone info at all and this is the : preceding the seconds
!       char sub2 = strBuf.charAt(strBuf.length()-5);
!       if (sub2 == '+' || sub2 == '-') {
!         //we have found timezone info of format +/-HH:MM
!         strBuf.setLength(strBuf.length()-5);
!         if (subsecond) {
!           strBuf.append('0').append("GMT").append(s.substring(s.length()-5));
} else {
!           strBuf.append("GMT").append(s.substring(s.length()-5));
!         }
!       } else if (subsecond) {
!         strBuf.append('0');
}
} else if (subsecond) {
strBuf = strBuf.append('0');
*** ./org/postgresql/jdbc2/ResultSet.java.orig	Fri May 25 16:23:34 2001
--- ./org/postgresql/jdbc2/ResultSet.java	Fri May 25 16:24:25 2001
***************
*** 484,497 ****
--- 484,519 ----
sbuf.setLength(0);
sbuf.append(s);

+       //we are looking to see if the backend has appended on a timezone.
+       //currently postgresql will return +/-HH:MM or +/-HH for timezone offset
+       //(i.e. -06, or +06:30, note the expectation of the leading zero for the
+       //hours, and the use of the : for delimiter between hours and minutes)
+       //if the backend ISO format changes in the future this code will
+       //need to be changed as well
char sub = sbuf.charAt(sbuf.length()-3);
if (sub == '+' || sub == '-') {
+         //we have found timezone info of format +/-HH
sbuf.setLength(sbuf.length()-3);
if (subsecond)  {
sbuf.append('0').append("GMT").append(s.substring(s.length()-3)).append(":00");
} else {
sbuf.append("GMT").append(s.substring(s.length()-3)).append(":00");
}
+       } else if (sub == ':') {
+         //we may have found timezone info of format +/-HH:MM, or there is no
+         //timezone info at all and this is the : preceding the seconds
+         char sub2 = sbuf.charAt(sbuf.length()-5);
+         if (sub2 == '+' || sub2 == '-') {
+           //we have found timezone info of format +/-HH:MM
+           sbuf.setLength(sbuf.length()-5);
+           if (subsecond)  {
+             sbuf.append('0').append("GMT").append(s.substring(s.length()-5));
+           } else {
+             sbuf.append("GMT").append(s.substring(s.length()-5));
+           }
+         } else if (subsecond) {
+           sbuf.append('0');
+         }
} else if (subsecond) {
sbuf.append('0');
}

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thanks. Applied.

Attached is a patch to fix the problem Thomas mentions below. The JDBC
driver now correctly handles timezones that are offset fractional hours
from GMT (ie. -06:30).

thanks,
--Barry

Thomas Lockhart wrote:

FYI, the reason I personally didn't want to apply this to 7.1.2 is
because we already added two new bugs in 7.1.1, and I didn't want to be
the one to add another. Add that to the natural problems I have with
JDBC, and I ran. :-)

Understandable. You shouldn't *have* to take responsibility for every
patch coming in, so feel free to leave some things for others. And if
there is a problem with this one, I'll understand if you need to yell at
me a little ;)

As a (sort of) aside, by forcing me to inspect the code we have
uncovered a problem with atypical time zones which we would not
otherwise have noticed, at least until someone in Newfoundland or India
stumbled on it. No patch yet, but at least we know it is there...

- Thomas

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

*** ./org/postgresql/jdbc1/ResultSet.java.orig	Fri May 25 16:23:19 2001
--- ./org/postgresql/jdbc1/ResultSet.java	Fri May 25 16:26:35 2001
***************
*** 472,484 ****
//so this code strips off timezone info and adds on the GMT+/-...
//as well as adds a third digit for partial seconds if necessary
StringBuffer strBuf = new StringBuffer(s);
char sub = strBuf.charAt(strBuf.length()-3);
if (sub == '+' || sub == '-') {
strBuf.setLength(strBuf.length()-3);
if (subsecond)  {
!         strBuf = strBuf.append('0').append("GMT").append(s.substring(s.length()-3, s.length())).append(":00");
} else {
!         strBuf = strBuf.append("GMT").append(s.substring(s.length()-3, s.length())).append(":00");
}
} else if (subsecond) {
strBuf = strBuf.append('0');
--- 472,506 ----
//so this code strips off timezone info and adds on the GMT+/-...
//as well as adds a third digit for partial seconds if necessary
StringBuffer strBuf = new StringBuffer(s);
+ 
+     //we are looking to see if the backend has appended on a timezone.
+     //currently postgresql will return +/-HH:MM or +/-HH for timezone offset
+     //(i.e. -06, or +06:30, note the expectation of the leading zero for the
+     //hours, and the use of the : for delimiter between hours and minutes)
+     //if the backend ISO format changes in the future this code will
+     //need to be changed as well
char sub = strBuf.charAt(strBuf.length()-3);
if (sub == '+' || sub == '-') {
strBuf.setLength(strBuf.length()-3);
if (subsecond)  {
!         strBuf.append('0').append("GMT").append(s.substring(s.length()-3, s.length())).append(":00");
!       } else {
!         strBuf.append("GMT").append(s.substring(s.length()-3, s.length())).append(":00");
!       }
!     } else if (sub == ':') {
!       //we may have found timezone info of format +/-HH:MM, or there is no
!       //timezone info at all and this is the : preceding the seconds
!       char sub2 = strBuf.charAt(strBuf.length()-5);
!       if (sub2 == '+' || sub2 == '-') {
!         //we have found timezone info of format +/-HH:MM
!         strBuf.setLength(strBuf.length()-5);
!         if (subsecond) {
!           strBuf.append('0').append("GMT").append(s.substring(s.length()-5));
} else {
!           strBuf.append("GMT").append(s.substring(s.length()-5));
!         }
!       } else if (subsecond) {
!         strBuf.append('0');
}
} else if (subsecond) {
strBuf = strBuf.append('0');
*** ./org/postgresql/jdbc2/ResultSet.java.orig	Fri May 25 16:23:34 2001
--- ./org/postgresql/jdbc2/ResultSet.java	Fri May 25 16:24:25 2001
***************
*** 484,497 ****
--- 484,519 ----
sbuf.setLength(0);
sbuf.append(s);

+       //we are looking to see if the backend has appended on a timezone.
+       //currently postgresql will return +/-HH:MM or +/-HH for timezone offset
+       //(i.e. -06, or +06:30, note the expectation of the leading zero for the
+       //hours, and the use of the : for delimiter between hours and minutes)
+       //if the backend ISO format changes in the future this code will
+       //need to be changed as well
char sub = sbuf.charAt(sbuf.length()-3);
if (sub == '+' || sub == '-') {
+         //we have found timezone info of format +/-HH
sbuf.setLength(sbuf.length()-3);
if (subsecond)  {
sbuf.append('0').append("GMT").append(s.substring(s.length()-3)).append(":00");
} else {
sbuf.append("GMT").append(s.substring(s.length()-3)).append(":00");
}
+       } else if (sub == ':') {
+         //we may have found timezone info of format +/-HH:MM, or there is no
+         //timezone info at all and this is the : preceding the seconds
+         char sub2 = sbuf.charAt(sbuf.length()-5);
+         if (sub2 == '+' || sub2 == '-') {
+           //we have found timezone info of format +/-HH:MM
+           sbuf.setLength(sbuf.length()-5);
+           if (subsecond)  {
+             sbuf.append('0').append("GMT").append(s.substring(s.length()-5));
+           } else {
+             sbuf.append("GMT").append(s.substring(s.length()-5));
+           }
+         } else if (subsecond) {
+           sbuf.append('0');
+         }
} else if (subsecond) {
sbuf.append('0');
}

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026