
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...

-- 
  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

Tue, 22 May 2001 14:03:26 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
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:

> 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...
> 


Tue, 22 May 2001 12:10:47 -0700
Barry Lind <barry@xythos.com>
Re: 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.

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

Tue, 22 May 2001 15:20:01 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: JDBC commit to 7.1.2

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

Tue, 22 May 2001 17:48:37 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Re: JDBC commit to 7.1.2
> 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

Tue, 22 May 2001 23:18:48 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: JDBC commit to 7.1.2
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
> 
>
Fri, 25 May 2001 17:00:59 -0700
Barry Lind <barry@xythos.com>
Patch for JDBC fractional hour timezone offset bug
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

Fri, 25 May 2001 20:44:09 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch for JDBC fractional hour timezone offset bug

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

Sun, 27 May 2001 20:36:54 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch for JDBC fractional hour timezone offset bug