OK, I found the problem.
I'm using Eclipse and I have two projects, my main app and my plug-ins. My main app has log4j-1.3alpha-8.jar in the build path. However, the plug-ins project uses log4j-1.2.7.jar. The plug-ins project is also on the build path of my main app. When I removed log4j-1.2.7.jar from the plug-ins project the GMT pattern works correctly as advertised. Of course that breaks my plug-ins project, so now I need to find a way to tell Eclipse to ignore that old jar file. Thanks so much for your help. Once you told me that it behaved in a similar manner to log4j 1.2.14 it made me think to check my build paths. Cheers, Eric -----Original Message----- From: Curt Arnold [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 9:53 PM To: Log4J Users List Subject: Re: UTC Time Stamps On Feb 7, 2007, at 4:55 PM, Eric Kolotyluk wrote: > C:\>java -version > > java version "1.6.0" > > Java(TM) SE Runtime Environment (build 1.6.0-b105) > > Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing) > > > > I'm running on Window XP SP 2 using Sun's JDK with > log4j-1.3alpha-8.jar > > I just added additional unit tests (bug 41565) that specify the timezone using property files and check the generated files for the expected timezone. The tests pass against both the current SVN HEAD and log4j 1.3alpha-8 (Sun Java 1.5.0_06 on Mac OS/X), but fail in a similar manner as you are describing when run against log4j 1.2.14. Any chance that you have an earlier log4j on your classpath and it is being used instead of log4j 1.3. The following statement should return the version information: String log4jImpl = org.lang.Package.getPackage ("org.apache.log4j").getImplementationVersion(); You could also try referencing a class that was introduced in log4j 1.3 that would not exist in log4j 1.2.x like org.apache.log4j.rolling.RollingFileAppender. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
