Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cEcYS-0002zO-Pe for pgsql-interfaces@arkaria.postgresql.org; Wed, 07 Dec 2016 13:46:40 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cEcYS-0006fA-4S for pgsql-interfaces@arkaria.postgresql.org; Wed, 07 Dec 2016 13:46:40 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cEcY6-0006HY-9b for pgsql-interfaces@postgresql.org; Wed, 07 Dec 2016 13:46:18 +0000 Received: from mail-io0-x236.google.com ([2607:f8b0:4001:c06::236]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cEcXy-0008D7-Cf for pgsql-interfaces@postgresql.org; Wed, 07 Dec 2016 13:46:16 +0000 Received: by mail-io0-x236.google.com with SMTP id c21so655980692ioj.1 for ; Wed, 07 Dec 2016 05:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6JbB4USI7bJ3BfYh/ya6WHTKBlLgHBzx33DnsutC9Bw=; b=sBzKE2gYTG9iULLpV4TcEmZGmCqDc/LQZjXrGOkulDgJrUkNjpvRg7edAKMlh+CBAb YvgxlPAWXLZ67dOkuNapHfNCacDHuxHnjttiY23Py9SHoNDStHE+0Fcr7m8j33qQNK48 tbKY3Q95zzNiB5hd94N2FVMYUmkrjc86sr07e2XGxhL8MXkKAVQ46ySsc8DowXgF8WHr NnG+UUD8YJRI0nSG7nTY3BYEfOih6VKUXelYl2ZnjBnDXLVvnbPZqYQ3GdNg++RgjHZD oCOa2zDgO4wysdT9X2Xd3seUQTeRc6tmL8R4kXmV3oCT3KbEAmNY7KSGpRM1bTivxoJj yGoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6JbB4USI7bJ3BfYh/ya6WHTKBlLgHBzx33DnsutC9Bw=; b=ff9gKH6EUWAC610OkFk44ZZrcefnNnNgoXFdI34RwkRbBfbZsuaBavCeHSShhcgZBi 4FPpKapvFTvhc6PXz/qs8I9ZjUS0YuZxLaUKtdi/KtXf2TGjgf2K5vYd26LhM5l4R58G 8eveQwcxmD4NaFpPH0h8z01KKLn2xLC/NB/J07b5S1iSO0vJ3DskyIasIw4yPUdWuc4w M5t/3p8Usj0y694vt2hB7r6PeHc/WB/wNCfykOB1YXWDRqMvtOhqC0fXu81jqY/bYwSN xmI083kQipaii6of3yNPhGpy9xacwzUbG4WyBmXs6JAyia/+o/iALOiIhlhY4Y7rFT7T jtpg== X-Gm-Message-State: AKaTC01bJBxrMYUxYCmy3nLeGuKTz+0PtiPX6H4qAeJD7CBQCQTjMJFxMz+8O5c8QmZST4wWgfxWYXO9Wd9vJw== X-Received: by 10.36.0.137 with SMTP id 131mr2104548ita.1.1481118368502; Wed, 07 Dec 2016 05:46:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.10.80 with HTTP; Wed, 7 Dec 2016 05:45:48 -0800 (PST) In-Reply-To: <6A395F497CE89A4693420F1134B3FDB896E4504D@LogiMail10.LogiXML.local> References: <6A395F497CE89A4693420F1134B3FDB896E4504D@LogiMail10.LogiXML.local> From: Dave Cramer Date: Wed, 7 Dec 2016 08:45:48 -0500 X-Google-Sender-Auth: oHZ5HakTGXg2IvlrKk2KdoYJuHI Message-ID: Subject: Re: User time zone ignored in JDBC/PostgreSql To: "Clifton B. Sothoron Jr." Cc: "pgsql-interfaces@postgresql.org" Content-Type: multipart/alternative; boundary=001a11c1428039a734054311be90 X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-interfaces Precedence: bulk Sender: pgsql-interfaces-owner@postgresql.org --001a11c1428039a734054311be90 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is actually an artifact of the JDBC spec which at the moment eludes me, but IIRC the time defaults to the time of the server running the application; not the server. AFAIK we don't even look at the user timezone. Not sure that helps Dave Cramer davec@postgresintl.com www.postgresintl.com On 6 December 2016 at 10:50, Clifton B. Sothoron Jr. < Clifton.SothoronJr@logianalytics.com> wrote: > I=E2=80=99ve created a user with a time zone of America/Chicago and a ser= ver time > zone of America/New York. I run the following query and America/New York = is > returned. The user time zone setting is ignored. It doesn=E2=80=99t seem = to be > usable via JDBC. > > > > select now(), extract(timezone FROM now()), current_setting('TIMEZONE'), > now()-interval '1 hour' as "1HourAgo" > > > > I don=E2=80=99t see any documented PostgreSQL JDBC connection properties = that > cause the user time zone to be honored. Is there a way to via a JDBC > connection to cause the user time zone to be used? > > > > Thanks in advance, > > > > Clifton Sothoron > > Senior Programmer > > Logi Analytics Inc. > > > --001a11c1428039a734054311be90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is actually an artifact of the JDBC spec which at the= moment eludes me, but IIRC the time defaults to the time of the server run= ning the application; not the server.

AFAIK we don't= even look at the user timezone.=C2=A0

Not sure th= at helps




On 6 December 2016 at 10:50, Clifton B. Soth= oron Jr. <Clifton.SothoronJr@logianalytics.com><= /span> wrote:

I=E2=80=99ve created a user with a time zone of Amer= ica/Chicago and a server time zone of America/New York. I run the following= query and America/New York is returned. The user time zone setting is igno= red. It doesn=E2=80=99t seem to be usable via JDBC.

=C2=A0

select now(), extract(timezone FROM now()), curr= ent_setting('TIMEZONE'), now()-interval '1 hour' as "1= HourAgo"

=C2=A0

I don=E2=80=99t see any documented PostgreSQL JDBC c= onnection properties that cause the user time zone to be honored. Is there = a way to via a JDBC connection to cause the user time zone to be used?=C2= =A0

=C2=A0

Thanks in advance,

=C2=A0

Clifton Sothoron

Senior Programmer

Logi Analytics Inc.

=C2=A0


--001a11c1428039a734054311be90--