Skip site navigation (1) Skip section navigation (2)

Re: Correction of how to use TimeZone by ControlFile(xlog.c)

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Magnus Hagander" <magnus(at)hagander(dot)net>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp>, <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Correction of how to use TimeZone by ControlFile(xlog.c)
Date: 2007-08-03 14:29:53
Message-ID: 87ir7wbsim.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-patches
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Fri, Aug 03, 2007 at 09:01:22AM -0400, Andrew Dunstan wrote:
>>>> Having talked a bit off-list with Hiroshi-san, he came up with the
>>>> suggestion taht we should be logging this information in UTC/GMT instead of
>>>> the servers timezone (for all cases, not just win32).
>
>>> Are you just talking about xlog.c? That wouldn't be an acceptable change 
>>> in elog.c, although we could provide additional escapes to output UTC if 
>>> needed.
>
>> Yes, just talking about xlog.c.
>
> I don't think it's an acceptable change in either place.  People who
> want to see UTC in their logs can start the postmaster in UTC.  Those
> who are accustomed to seeing local time will squawk.

It would probably make sense to use UTC in the CSV logs since they're intended
to be machine readable. Whatever program is used to read them can handle
displaying the timestamps in the appropriate timezone for user's consumption.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com


In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2007-08-03 14:44:08
Subject: Re: Correction of how to use TimeZone by ControlFile(xlog.c)
Previous:From: Tom LaneDate: 2007-08-03 13:49:57
Subject: Re: Correction of how to use TimeZone by ControlFile(xlog.c)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group