Hi, I still have not received a response to this mail I posted a while
ago.

 

I really want to use the {GMT} feature so I can align our client logs
with our server logs (which may be in different time zones). I would
really appreciate it if someone could please help me get this working.

 

Cheers, Eric

 

-----Original Message-----
From: Eric Kolotyluk 
Sent: Monday, January 08, 2007 12:33 PM
To: [email protected]
Subject: RE: UTC Time Stamps

 

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.ddHH: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

 

Reply via email to