Re: Timezone for %t log_line_prefix
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
Import Notes
Reply to msg id not found: 41115761.2030202@pse-consulting.deReference msg id not found: 41115761.2030202@pse-consulting.de
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
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?
says this about strftime:
*%z*, *%Z*
Either the time-zone name or time zone abbreviation, depending on
registry settings; no characters if time zone 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