Thread: Timezone for %t log_line_prefix
If %t is used in log_line_prefix, win32's strftime will print a very long timezone information, e.g. "W. Europe Daylight Time" where Linux would write "UTC". This makes the timestamp consuming more than half of an average line length. Do we have alternatives to the long form? Do we need the timezone information at all? We know already it's the server's time. Another alternative would be a short timestamp (%t vs. %T) to have both. Regards, Andreas
Andreas Pflug wrote: > If %t is used in log_line_prefix, win32's strftime will print a very > long timezone information, e.g. "W. Europe Daylight Time" where Linux > would write "UTC". This makes the timestamp consuming more than half > of an average line length. > Do we have alternatives to the long form? Do we need the timezone > information at all? We know already it's the server's time. Another > alternative would be a short timestamp (%t vs. %T) to have both. > > That's ugly, and unfortunately %z is GNU-specific. The quick fix for now does seem to be providing alternative forms - %T and %S make sense. Of course, if we wanted it *really* short we could just print out the current epoch time in 8 hex digits :-) cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Andreas Pflug wrote:
>> If %t is used in log_line_prefix, win32's strftime will print a very
>> long timezone information, e.g. "W. Europe Daylight Time" where Linux
>> would write "UTC". This makes the timestamp consuming more than half
>> of an average line length.
>> Do we have alternatives to the long form? Do we need the timezone
>> information at all? We know already it's the server's time. Another
>> alternative would be a short timestamp (%t vs. %T) to have both.
> That's ugly, and unfortunately %z is GNU-specific.
Does Windows' strftime have any short zone name %-spec? Seems like a
quick #ifdef WIN32 to use a more compact zone name would be the best
solution.
I'd be inclined to leave out the zone field *on Windows only* if there
is no %-spec that uses something more reasonable. I don't think this
problem justifies adding more %-options to log_line_prefix.
regards, tom lane
Tom Lane wrote: > > Does Windows' strftime have any short zone name %-spec? Seems like a > quick #ifdef WIN32 to use a more compact zone name would be the best > solution. I already checked; unfortunately there's no short zone option. %z and %Z give identical output. > > I'd be inclined to leave out the zone field *on Windows only* if there > is no %-spec that uses something more reasonable. I don't think this > problem justifies adding more %-options to log_line_prefix. I don't have a problem with either way, but it appears desirable if there would be a log_line_prefix option that gives identical result on all systems. Regards, Andreas
Well, I see this in pgtz.c:
{"Eastern Standard Time", "Eastern Daylight Time", "US/Eastern"}, /* (GMT-05:00) Eastern Time (US &
Canada)*/
Can't we use this to map to slightly shorter names?
---------------------------------------------------------------------------
Andreas Pflug wrote:
> Tom Lane wrote:
> >
> > Does Windows' strftime have any short zone name %-spec? Seems like a
> > quick #ifdef WIN32 to use a more compact zone name would be the best
> > solution.
>
> I already checked; unfortunately there's no short zone option. %z and %Z
> give identical output.
>
> >
> > I'd be inclined to leave out the zone field *on Windows only* if there
> > is no %-spec that uses something more reasonable. I don't think this
> > problem justifies adding more %-options to log_line_prefix.
>
> I don't have a problem with either way, but it appears desirable if
> there would be a log_line_prefix option that gives identical result on
> all systems.
>
> Regards,
> Andreas
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
Andreas Pflug <pgadmin@pse-consulting.de> writes:
> I don't have a problem with either way, but it appears desirable if
> there would be a log_line_prefix option that gives identical result on
> all systems.
Well, the Right Thing (TM) would be to use our src/timezone code instead
of the local C library. The reason I didn't do that was that I thought
the log timestamps shouldn't be affected by whatever TimeZone happens to
be set in a particular backend.
Since we do have control over the timezone library now, one possible
answer is to extend the src/timezone API so that it's possible to
convert/format against more than a single timezone. We could then
remember the zone setting inherited from the postmaster and always use
that when formatting timestamps for the log, while not changing the
behavior for operations at the SQL level.
However, this is probably a bit more work than is reasonable to
undertake right now, when we're already overdue for beta. For the
moment I'm really thinking that we ought to just #ifdef out the %Z
on Windows, and plan to do something nicer in 8.1.
regards, tom lane
Tom Lane said: > > Since we do have control over the timezone library now, one possible > answer is to extend the src/timezone API so that it's possible to > convert/format against more than a single timezone. We could then > remember the zone setting inherited from the postmaster and always use > that when formatting timestamps for the log, while not changing the > behavior for operations at the SQL level. > > However, this is probably a bit more work than is reasonable to > undertake right now, when we're already overdue for beta. For the > moment I'm really thinking that we ought to just #ifdef out the %Z on > Windows, and plan to do something nicer in 8.1. > I think this counts as a bug, but I don't see that it needs to hold up the beta release - I am assuming we expect several betas before we go gold. Could it be fixed nicely in the next week or so? cheers andrew
Tom Lane <tgl@sss.pgh.pa.us> writes: > However, this is probably a bit more work than is reasonable to > undertake right now, when we're already overdue for beta. For the > moment I'm really thinking that we ought to just #ifdef out the %Z > on Windows, and plan to do something nicer in 8.1. Could it just print numeric time zones on windows? -- greg
Greg Stark wrote: >Tom Lane <tgl@sss.pgh.pa.us> writes: > > > >>However, this is probably a bit more work than is reasonable to >>undertake right now, when we're already overdue for beta. For the >>moment I'm really thinking that we ought to just #ifdef out the %Z >>on Windows, and plan to do something nicer in 8.1. >> >> > >Could it just print numeric time zones on windows? > > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_strftime.2c_.wcsftime.asp says this about strftime: *%z*, *%Z* Either the time-zone name or time zone abbreviation, depending on registry settings; no characters if timezone is unknown So I don't think we can. One thought I did have was that we could force UTC on Windows as a quick fix. cheers andrew
>> That's ugly, and unfortunately %z is GNU-specific. > >Does Windows' strftime have any short zone name %-spec? Seems like a >quick #ifdef WIN32 to use a more compact zone name would be the best >solution. No. This is what the cruft in pgtz.c (TZABBREV macro and associated function) was all about. //Magnus
>Since we do have control over the timezone library now, one possible >answer is to extend the src/timezone API so that it's possible to >convert/format against more than a single timezone. We could then >remember the zone setting inherited from the postmaster and always use >that when formatting timestamps for the log, while not changing the >behavior for operations at the SQL level. Time permitting, I was planning to address this in 8.1. (well, 7.6 then, but I guess it's 8.1 now). Not specificalyl the issue, but the groundwork API change to make it possible. >However, this is probably a bit more work than is reasonable to >undertake right now, when we're already overdue for beta. Definitly. //Magnus