Log line prefix on win32
On my german Windows XP Professional, %t in log_line_prefix produces
2004-09-18 14:23:26 Westeurop�ische Sommerzeit
This is rather long and ugly. It is already on the open item list:
* shorten timezone for %t log_line_prefix
Additionally I would suggest something like %z. Most of the time, time zone
information is irrelevant for me in server logs.
Best Regards,
Michael Paesold
I am still trying to figure out a good way to fix this. On unix my log
shows EDT but Win32 shows US/Eastern and some zones are much longer.
Should we add %z and not print the timezone information for %t? That
seems like the only reasonable solution.
---------------------------------------------------------------------------
Michael Paesold wrote:
On my german Windows XP Professional, %t in log_line_prefix produces
2004-09-18 14:23:26 Westeurop?ische SommerzeitThis is rather long and ugly. It is already on the open item list:
* shorten timezone for %t log_line_prefix
Additionally I would suggest something like %z. Most of the time, time zone
information is irrelevant for me in server logs.Best Regards,
Michael Paesold---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
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, Pennsylvania 19073
Bruce Momjian wrote:
I am still trying to figure out a good way to fix this. On unix my log
shows EDT but Win32 shows US/Eastern and some zones are much longer.
"W. Europe Daylight Time" on my system.
Should we add %z and not print the timezone information for %t? That
seems like the only reasonable solution.
+1 vote from me. IMHO TZ information which is constant on the machine
anyway can safely be omitted.
Regards,
Andreas
Andreas Pflug wrote:
Bruce Momjian wrote:
I am still trying to figure out a good way to fix this. On unix my log
shows EDT but Win32 shows US/Eastern and some zones are much longer."W. Europe Daylight Time" on my system.
Should we add %z and not print the timezone information for %t? That
seems like the only reasonable solution.+1 vote from me. IMHO TZ information which is constant on the machine
anyway can safely be omitted.
Another possibility would be to have alternatives for %t and %s which
used UTC rather than local time (and so of course didn't use a
timezone). Or maybe we could do both.
cheers
andrew
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I am still trying to figure out a good way to fix this. On unix my log
shows EDT but Win32 shows US/Eastern and some zones are much longer.
Should we add %z and not print the timezone information for %t? That
seems like the only reasonable solution.
%z is not standard --- you won't find it in the SUS spec for instance.
Or were you thinking of exposing this problem at the API level by making
people write a separate log_line_prefix item to get the timezone? I'm
not thrilled about institutionalizing such a fix for a platform-specific
issue that might go away later (if we switch to using our own timezone
code here, for instance).
I'd be inclined to #ifdef elog's strftime calls so that the zone is
omitted on Windows but not elsewhere. Kinda ugly but it's a localized
fix that we can easily improve later.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I am still trying to figure out a good way to fix this. On unix my log
shows EDT but Win32 shows US/Eastern and some zones are much longer.
Should we add %z and not print the timezone information for %t? That
seems like the only reasonable solution.%z is not standard --- you won't find it in the SUS spec for instance.
Or were you thinking of exposing this problem at the API level by making
people write a separate log_line_prefix item to get the timezone? I'm
I was thinking of adding %z as an option to log_line prefix, so to get
the current output you would do '%t %z'. I was not suggesting changing
the %Z passed to strftime if they ask for timezone.
not thrilled about institutionalizing such a fix for a platform-specific
issue that might go away later (if we switch to using our own timezone
code here, for instance).
Right.
I'd be inclined to #ifdef elog's strftime calls so that the zone is
omitted on Windows but not elsewhere. Kinda ugly but it's a localized
fix that we can easily improve later.
Yes, we could go that way too. The decision is a platform-specific change
or omitting it for all outputs.
--
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, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
I was thinking of adding %z as an option to log_line prefix, so to get
the current output you would do '%t %z'. I was not suggesting changing
the %Z passed to strftime if they ask for timezone.
I think this is a bad idea, mainly because you couldn't easily get the
same output. It would be almost the same, except when you crossed a DST
boundary in between the two calls to strftime; in which case you'd get a
completely misleading result.
I believe that in the long run we will stop using the platform-specific
strftime at all, and go over to using just our own code, which makes
this not a permanent problem but just an artifact of the fact that we
haven't completely finished the process of absorbing src/timezone/.
So I'd rather not invent an API element simply because Windows' strftime
sucks.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I was thinking of adding %z as an option to log_line prefix, so to get
the current output you would do '%t %z'. I was not suggesting changing
the %Z passed to strftime if they ask for timezone.I think this is a bad idea, mainly because you couldn't easily get the
same output. It would be almost the same, except when you crossed a DST
boundary in between the two calls to strftime; in which case you'd get a
completely misleading result.I believe that in the long run we will stop using the platform-specific
strftime at all, and go over to using just our own code, which makes
this not a permanent problem but just an artifact of the fact that we
haven't completely finished the process of absorbing src/timezone/.
So I'd rather not invent an API element simply because Windows' strftime
sucks.
Agreed, and the daylight savings time is a good reason to keep the
timezone.
However, I actually prefer the mail header style of timezone to EST/EDT
anyway:
Fri, 08 Oct 2004 12:37:52 -0400
Ours would change from:
2004-10-08 11:29:30 EDT LOG: database system was shut down at
to
2004-10-08 11:29:30 -0400 LOG: database system was shut down at
Is that better?
--
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, Pennsylvania 19073Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I was thinking of adding %z as an option to log_line prefix, so to get
the current output you would do '%t %z'. I was not suggesting changing
the %Z passed to strftime if they ask for timezone.I think this is a bad idea, mainly because you couldn't easily get the
same output. It would be almost the same, except when you crossed a DST
boundary in between the two calls to strftime; in which case you'd get a
completely misleading result.I believe that in the long run we will stop using the platform-specific
strftime at all, and go over to using just our own code, which makes
this not a permanent problem but just an artifact of the fact that we
haven't completely finished the process of absorbing src/timezone/.
So I'd rather not invent an API element simply because Windows' strftime
sucks.
However tz is implemented, I'd like to see a log_line_prefix option
which simply omits the TZ, which is noise for me.
Regards,
Andreas
Bruce Momjian <pgman@candle.pha.pa.us> writes:
However, I actually prefer the mail header style of timezone to EST/EDT
anyway:
Agreed, but AFAIK there's no portable way to ask strftime for that,
so you're still stuck with a compatibility problem. We could teach
pg_strftime to do it, but that's something for 8.1 or beyond.
regards, tom lane
Andreas Pflug wrote:
"W. Europe Daylight Time" on my system.
With my german system it is "Westeurop�ische Sommerzeit".
which is longer then the actual timestamp:
2004-09-26 11:56:55
Westeurop�ische Sommerzeit
Any fix is appreciated!
Best Regards,
Michael Paesold
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
However, I actually prefer the mail header style of timezone to EST/EDT
anyway:Agreed, but AFAIK there's no portable way to ask strftime for that,
so you're still stuck with a compatibility problem. We could teach
pg_strftime to do it, but that's something for 8.1 or beyond.
OK, the attached applied patch suppresses timezone output from
log_line_prefix %t on Win32. Also added to TODO:
Win32
o Re-enable timezone output on log_line_prefix '%t' when a
shorter timezone string is available
--
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, Pennsylvania 19073Attachments:
/bjm/difftext/plainDownload
Index: src/backend/utils/error/elog.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/error/elog.c,v
retrieving revision 1.152
diff -c -c -r1.152 elog.c
*** src/backend/utils/error/elog.c 7 Oct 2004 15:21:54 -0000 1.152
--- src/backend/utils/error/elog.c 9 Oct 2004 01:21:37 -0000
***************
*** 1391,1397 ****
--- 1391,1402 ----
char strfbuf[128];
strftime(strfbuf, sizeof(strfbuf),
+ /* Win32 timezone names are too long so don't print them. */
+ #ifndef WIN32
"%Y-%m-%d %H:%M:%S %Z",
+ #else
+ "%Y-%m-%d %H:%M:%S",
+ #endif
localtime(&stamp_time));
appendStringInfoString(buf, strfbuf);
}