Thanks for the info. I reviewed the bug information too. I'm still not
sure what to do next.
I'm using the following pattern in my Logging.properties file
log4j.rootLogger=INFO, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%-5p %d{yyyy.MM.dd
HH:mm:ss,SSS}{GMT} Z [%t] %c{1} - %m%n
and this is what I get in the log file
INFO 2007.01.04 07:47:45,454{GMT} Z . . .
Where the time is definitely not GMT. We're using Java 1.4.2_12 as a
runtime. The 1.4.2 javadoc seems to indicate that GMT is an acceptable
timezone. It looks as though PatternLayout is not recognizing the second
set of braces after %d{yyyy.MM.dd HH:mm:ss,SSS}
>From the bug report you say
Modifies PatternParser to allow each conversion specification to have
multiple options enclosed in braces and interprets the second option
following %d to specify the time zone. For example, the following
format should result in the UTC time and the local time starting the
formatted logging event:
%d{yyyy-MM-dd HH:mm:ss}{GMT}Z %d{HH:mm:ss Z} %c - %m%n
According to the 1.3 javadoc - Most of the work of the PatternLayout
class is delegated to the PatternParser class. Is something getting lost
between PatternParser and PatternLayout?
Here is some of the text from the 1.3 javadoc of PatternLayout
d - Used to output the date of the logging event. The date conversion
specifier may be followed by a set of braces containing a date and time
pattern strings SimpleDateFormat, ABSOLUTE, DATE or ISO8601. For
example, %d{HH:mm:ss,SSS}, %d{dd MMM yyyy HH:mm:ss,SSS} or %d{DATE}. If
no date format specifier is given then ISO8601 format is assumed.
This gives no example that
%d{yyyy-MM-dd HH:mm:ss}{GMT}
is supported. If this is supported it would probably be a good idea to
update the javadoc with an example.
Am I configuring something wrong or is the implementation incomplete?
Cheers, Eric
As an aside, is there any estimate when log4j 2.0 will be released?
-----Original Message-----
From: Curt Arnold [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 9:33 PM
To: Log4J Users List
Subject: Re: UTC Time Stamps
On Jan 2, 2007, at 12:04 PM, Eric Kolotyluk wrote:
> I found a few articles on the web which claimed that UTC time
> formatting
> would be supported in log4j 1.3, and could be used in a form like
>
> %d{yyyy.MM.dd HH:mm:ss,SSS}{GMT}
> or
> %d{yyyy.MM.dd HH:mm:ss,SSS}{UTC}
>
> I'm using log4j 1.3-alpha-8, and neither seems to work, nor can I find
> any indication in the javadoc that this feature is supported.
>
> This is an exceptionally useful feature to have when you have to
> compare
> log files from computers in different time zones.
>
The feature was implemented as bug 32064 (http://issues.apache.org/
bugzilla/show_bug.cgi?id=32064). The most critical code to look at
to diagnose a failure would start at line 91 in
org.apache.log4j.pattern.DatePatternConverter. I have not heard a
report of a failure and there are unit tests that should fail if the
feature is not functioning (particularly
o.a.l.pattern.PatternParserTest.testMultiOption. Is there anything
unusual about your choice of JVM, platform, et al? The documentation
for java.util.TimeZone should be checked to see if your options are
valid time zones on the JVM (i.e. they work with
TimeZone.getTimeZone). You might try GMT+0 since that is explicit in
the documentation (in JDK 1.4), but just GMT isn't.
> As an aside, is there any chance a production version of 1.3 will be
> available in 2007?
Actually, I don't ever foresee a production version of 1.3 as its
version number suggests drop in compatibility with log4j 1.2 and it
would be impractical to make it strictly compatible with log4j 1.2 as
compatibility wasn't guarded during the log4j 1.3 development
process. My personal goal has been to leapfrog 1.3 with an log4j 2.0
that would be designed for JDK 1.5 and later. Some log4j 1.3 have
been backported to log4j 1.2. I haven't looked at trying to
implement time zones on log4j 1.2. If you'd like to take a shot,
please feel free.
>
> Cheers, Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
