On Fri, Feb 21, 2014 at 12:43 AM, Andrew Sullivan wrote:
> Do you control the client code? If so, why not set the TimeZone
> locally when you connect? That's the right way to handle this,
> really.
>
Agree. So find the OS timezone at programming level and set accordingly.
This can be done eithe
On Fri, Feb 21, 2014 at 12:14:42AM +0530, Dev Kumkar wrote:
> These are the two clients which I have currently who communicate with
> database.
>
Do you control the client code? If so, why not set the TimeZone
locally when you connect? That's the right way to handle this,
really.
A
--
Andrew
On Thu, Feb 20, 2014 at 9:30 PM, Adrian Klaver wrote:
>
> So what is your requirement?
> Do you have a specific application/use for the databases you are
> installing?
There are two interfaces for the database. One is from the ODBC driver and
other is from the JDBC driver.
These are the two clie
On 02/20/2014 04:59 AM, Dev Kumkar wrote:
On Thu, Feb 20, 2014 at 4:31 AM, Adrian Klaver
mailto:adrian.kla...@aklaver.com>> wrote:
It depends on how you are declaring the timestamp field. If you do
not use with time zone then the input value is open to
interpretation and is not 'anc
On 02/20/2014 04:29 AM, Dev Kumkar wrote:
On Thu, Feb 20, 2014 at 3:53 AM, Adrian Klaver
mailto:adrian.kla...@aklaver.com>> wrote:
Each driver will have its own behavior. For an explanation of the
JDBC behavior see here:
http://www.postgresql.org/__message-id/4B2F2CED.10400@__opencl
On Thu, Feb 20, 2014 at 4:31 AM, Adrian Klaver wrote:
> It depends on how you are declaring the timestamp field. If you do not use
> with time zone then the input value is open to interpretation and is not
> 'anchored' to a point in time.
>
> Example
>
> My time zone is currently PST.
> test=> cr
inline:
On Thu, Feb 20, 2014 at 3:57 AM, Tom Lane wrote:
>
> The functionality of determining an IANA timezone name equivalent to the
> platform's behavior is currently embedded in initdb and isn't separately
> accessible. So you've got several options:
>
Hmm, actually was looking for exact that
On Thu, Feb 20, 2014 at 3:55 AM, Terence Ferraro
wrote:
> Or, if you don't mind a little patching: http://pastebin.com/5AyaX2RF
>
> That restores the pre-9.1 functionality of determining the timezone on
> postmaster start. As has been pointed out, their new stuff is more useful
> if you're shippin
On Thu, Feb 20, 2014 at 3:53 AM, Adrian Klaver wrote:
> Each driver will have its own behavior. For an explanation of the JDBC
> behavior see here:
>
> http://www.postgresql.org/message-id/4b2f2ced.10...@opencloud.com
>
>
> Per Andrews posts, the least surprise behavior is to explicitly set the
>
On 02/19/2014 01:52 PM, Dev Kumkar wrote:
On Thu, Feb 20, 2014 at 2:49 AM, Andrew Sullivan mailto:a...@crankycanuck.ca>> wrote:
No, select now() would return the time in whatever timezone is set, or
the timezone that the server defaulted to if there's nothing set by
the client. So i
Dev Kumkar writes:
> On Thu, Feb 20, 2014 at 3:07 AM, Adrian Klaver
> wrote:
>> Do you know where the machine is going when you do the install?
> No if that was the case then target could have set before shipping itself.
> Machine TGT-Region is not known here.
The functionality of determining a
Or, if you don't mind a little patching: http://pastebin.com/5AyaX2RF
That restores the pre-9.1 functionality of determining the timezone on
postmaster start. As has been pointed out, their new stuff is more useful
if you're shipping instances to the farthest reaches of the planet (We've
only got
On Thu, Feb 20, 2014 at 3:40 AM, Andrew Sullivan wrote:
> I think your client should set the TimeZone at connection time.
> That's going to yield the most predictable behaviour for the users, I
> suspect.
Agree! But nothing special is done at JDBC level, is the JDBC driver
setting things like Ti
On 02/19/2014 02:07 PM, Dev Kumkar wrote:
On Thu, Feb 20, 2014 at 3:26 AM, Andrew Sullivan mailto:a...@crankycanuck.ca>> wrote:
On Thu, Feb 20, 2014 at 03:22:15AM +0530, Dev Kumkar wrote:
>
> Hmm. Missed one observation here, created a test table with timestamp
> column of typ
On Thu, Feb 20, 2014 at 03:37:20AM +0530, Dev Kumkar wrote:
> But better is to set the TimeZone. Now haven't done anything special but
> JDBC is working with setting TimeZone and ODBC not. So what should I look
> from here now?
I think your client should set the TimeZone at connection time.
That's
On Thu, Feb 20, 2014 at 3:26 AM, Andrew Sullivan wrote:
> On Thu, Feb 20, 2014 at 03:22:15AM +0530, Dev Kumkar wrote:
> >
> > Hmm. Missed one observation here, created a test table with timestamp
> > column of type 'default current_timestamp'.
> > When the query is executed from JDBC then it store
On Thu, Feb 20, 2014 at 03:22:15AM +0530, Dev Kumkar wrote:
>
> Hmm. Missed one observation here, created a test table with timestamp
> column of type 'default current_timestamp'.
> When the query is executed from JDBC then it stores OS specific local time
> into this column.
Probably the JDBC dr
On Thu, Feb 20, 2014 at 3:07 AM, Adrian Klaver wrote:
>
> Do you know where the machine is going when you do the install?
No if that was the case then target could have set before shipping itself.
Machine TGT-Region is not known here.
Regards...
On Thu, Feb 20, 2014 at 2:49 AM, Andrew Sullivan wrote:
> No, select now() would return the time in whatever timezone is set, or
> the timezone that the server defaulted to if there's nothing set by
> the client. So in your installation, set up the server to use UTC by
> default and, if you like,
On 02/19/2014 01:16 PM, Dev Kumkar wrote:
On Thu, Feb 20, 2014 at 2:32 AM, Andrew Sullivan mailto:a...@crankycanuck.ca>> wrote:
Try issuing SET TimeZone commands. I think you'll find that the
client can set whatever time zone it wants.
I think am not being heard incorrectly here.
Her
On Thu, Feb 20, 2014 at 02:46:46AM +0530, Dev Kumkar wrote:
> Since the database is created on SRC-INDIA the timezone parameter gets set
> as "Asia/Calcutta", but when shipped locally then now() would return
> incorrect time as per target TGT-USA local time.
>
No, select now() would return the ti
On Thu, Feb 20, 2014 at 2:32 AM, Andrew Sullivan wrote:
> Try issuing SET TimeZone commands. I think you'll find that the
> client can set whatever time zone it wants.
I think am not being heard incorrectly here.
Here is the scenario - Database is created using binaries and not
postgreSQL inst
On 02/19/2014 01:02 PM, Andrew Sullivan wrote:
On Thu, Feb 20, 2014 at 02:24:53AM +0530, Dev Kumkar wrote:
Ok but am confused then, as if no timezone parameter is defined in
postgreSQL.conf file then yes UTC time is returned. "Select now()"
but if timezone parameter is set then "Select now()" re
On Thu, Feb 20, 2014 at 02:24:53AM +0530, Dev Kumkar wrote:
> Ok but am confused then, as if no timezone parameter is defined in
> postgreSQL.conf file then yes UTC time is returned. "Select now()"
> but if timezone parameter is set then "Select now()" returns date time as
> per timezone.
Try issu
On Thu, Feb 20, 2014 at 2:06 AM, John R Pierce wrote:
> postgres handles timezones on a per client connection basis. the server
> itself doesn't really care what timezone it is running in. 'timestamp with
> time zone' data is internally stored in the equivalent of UTC, and
> converted to/from th
On 2/19/2014 11:59 AM, Dev Kumkar wrote:
Hmm. Is there any postgreSQL command/binary which can be used to set
timezone according to OS one.
At the time of postgreSQL install how does it pick timezone
information and sets into postgreSQL.conf accordingly.
postgres handles timezones on a per c
On Wed, Feb 19, 2014 at 8:31 PM, Tom Lane wrote:
> If you mean you would like to use Windows' timezone data, the answer is
> you can't --- and you generally shouldn't want to, because AFAIK their
> timezone data is pretty sucky: it's incomplete and not terribly accurate
> about historical details
Dev Kumkar writes:
> How to set timezone in postgreSQL database to pick operating system level
> timezone information.
If you mean you would like to use Windows' timezone data, the answer is
you can't --- and you generally shouldn't want to, because AFAIK their
timezone data is pretty sucky: it's
How to set timezone in postgreSQL database to pick operating system level
timezone information.
In postgresql.conf there exists "timezone" parameter whose value can be set.
However this value needs to be in format 'US/Pacific', 'Asia/Calcutta' and
so on to work correctly.
Is there any database qu
29 matches
Mail list logo
