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

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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Hiroshi Saito <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,pgsql-patches(at)postgresql(dot)org
Subject: Re: Correction of how to use TimeZone by ControlFile(xlog.c)
Date: 2007-08-03 13:04:45
Message-ID: 20070803130445.GF30042@svr2.hagander.net (view raw or flat)
Thread:
Lists: pgsql-patches
On Fri, Aug 03, 2007 at 09:01:22AM -0400, Andrew Dunstan wrote:
> >>>>[ patch to use pg_strftime in xlog.c ]
> >>>>        
> >>>This code deliberately does not use pg_strftime, for the same reasons
> >>>that elog.c doesn't use it.
> >>>
> >>>I'm inclined to think that an appropriate fix is the same as we use in
> >>>elog.c, ie, don't use %Z at all under Windows.
> >>>      
> >>Eh? Do you mean this change? 
> >>"%Y-%m-%d %H:%M:%S %Z" to "%Y-%m-%d %H:%M:%S"
> >>That tzname is expressed here does not regard me as a problem.
> >>Probably, elog.c has still more nearly another problem.
> >>    
> >
> >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). That would make
> >things equally "safe" wrt changes in the pg timezone, and always
> >predictable. 
> >
> >Thoughts on this?
> >
> >
> >  
> 
> 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.

//Magnus

In response to

Responses

pgsql-patches by date

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

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