Bugzilla – Bug 3736
log4j timestamps are not ISO 8601 compatible
Last modified: 2006-10-26 16:19:02
You need to
before you can comment on or make changes to this bug.
the log4j produces timestamps like
2005-09-08 22:35:56,101 INFO exec.StateMachine ...
which are neither ISO 8601 compliant nor unambigous. There are three issues with
the time stamp above:
 It is ambigious. If I were to parse a logfile that was produced elsewhere in
the world, without time zone identification, it is hopeless. ISO 8601 says to
use either a zone offset for local time, or Z for UTC, if the stamps are to be
 The date and time of a timestamp are separated by a "T" according to ISO
8601. The wording can also to be read - in certain cases - that "T" can be
omitted. However, a space as separator between date and time is not permitted AFAIK.
 The separator between seconds and subseconds has to be "." (period). This is
supposedly fixed in newer releases of log4j.
Valid formats for ISO 8601 time stamps include the XML schema type xs::dateTime.
Examples can be seen using GNU's "date -Isec". More examples include:
I would pick example 7/8.
How about this format: '2002-05-23 14:04:27.166-05:00'?
AFAI understand it, and I may read it wrong, you can s/T//, but not
s/T/ /. Thus, replacing "T" with space " " would not be permissable. See  in
However, one may get away on a technicality (have to re-read the draft I have
here somewhere) by claiming that the Jarek's version is two timestamps, one date
and one time.
Note: Dropping the T is often applied to the concise (no "-" in date, no ":" in
time) format. I agree that s/T/ / is more readible. We can check with XML schema
what inputs xs::dateTime will accept.
Given the discussion on gt-dev (initial thread:
http://www.globus.org/mail_archive/gt-dev/2006/10/msg00044.html) we decided on
the following format:
Updated the log4j configuration file to print out the timestamp in the agreed
format. Changes commited to trunk.