Setting the Time Zone to UTC does enable correlation of events across servers in different time zones (assuming they are all synchronized with a common time source). WebSphere MQ stores all timestamps in UTC for that reason. For a distributed application, this can be useful.
If the user can set the TZ at the appender level, why not support a TZ at the repository level as well? Most of the time it won't be used, but if a user wants all appenders to use a non-default TZ they can set it there.
The distributed app scenario also supports the outputting of events through different appenders in different languages. I worked on a large airline reservations system in Germany a while back that had support groups in Germany, France and Italy. I'm sure they would have liked to see events in their own language. It also comes into play for product support--a support group may want a customer to enable an appender for troubleshooting and have the events output in the language they understand, not the language the customer uses.
Mark Durman
| Curt Arnold <[EMAIL PROTECTED]>
12/21/2004 09:16 AM
|
|
On Dec 21, 2004, at 10:44 AM, Ceki Gülcü wrote:
> At 12:01 AM 12/21/2004, Curt Arnold wrote:
>
> The Object to String conversion is done once and only once. The result
> is cached and subsequently shared by all appenders. While I can
> imagine having two emails (thus two layouts) having different
> timezones, I can't see the use case for outputting an event in German
> through one appender, Dutch in another and in English in a third.
>
I think the multi-locale use case is reasonable, however it may be one
that we reject as a requirement. I'd like to see how it plays out
before rejecting it.
>> Locale and timezone, like layout, are accommodations of the
>> preferences of a particular audience being reached through the
>> appender. Can you think of reasons that you would want to specify
>> them at a higher level?
>
> I have to admit that I actually have a hard time imagining any use for
> setting the TimeZone because:
>
> 1) if events are to be viewed locally, they will be formatted using
> the system default TimeZone which is usually the same as the desired
> TimeZone.
>
> 2) if events need to be viewed remotely, they are transmitted in a
> TZ-neutral form over the wire. The recipient can output the event in
> its local TimeZone.
>
> The only remaining case is then the user wanting to output the event
> in a TZ other than that of the her system (default) TZ. However, in
> that case we could ask the user to specify a non default TZ for each
> of her PatternLayouts that require it. No need to specify it at the
> LoggerRepository level.
I would think the most common use for an arbitrary timezone would be to
specify that the time should be rendered as UTC. I do think that is
still at the layout level (whether or not embedded in the pattern
specification)
>
>> Implementing appender level locale rendering would likely involve
>> creating threads to do rendering on non-default locales in some
>> instances and would likely have some performance hit, but shouldn't
>> significantly performance when not specified. However, it is going
>> to take some experimentation to see where it can be effectively
>> performed.
>
> The conjunction of the words "level" and "locale" made me think of the
> case where the level string was output in the user's locale. So,
> English speaking users would see TRACE, DEBUG, INFO, WARN, ERROR,
> EMERG a French speaker would see TRACE, BOGUE, INFO, AVERTISSEMENT,
> ERREUR, URGENCE a Turkish speaker would see IZ, DEBUG, BILGI, DIKKAT,
> YANLIS, IMDAT.
>
I think working the locale issue through is going to take some
experimentation. It would probably be best to take a shot at a
regexp-based message localizing layout. Once we have that piece, then
we can experiment on the localization of level names and
ObjectRendering. However, I've going to have to say that I can't do
that until after log4cxx 0.9.8 snapshot is stable.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
