Re: 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 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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 <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073