You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Michael A. McAngus" <ma...@infinet.com> on 2002/06/09 20:45:40 UTC
Re: Updating millisecond timestamps.
I don't know if the previous email, and this one, is the correct way for non-Contributors to submit changes. I saw no responses to the previous email, so if I'm doing things incorrectly, please let me know the correct proceedure.
I found two problems with my previous submission:
1. It broke the LogFactor5 (lf5) contributions.
2. It introduced a bug that I didn't notice when I was testing (I need to set up JUnit, and create test cases).
Attached are updated versions of all the files, and diff files that identify the changes.
The changes from log4j original source are as follows:
o.a.l.helpers.AbsoluteTimeDateFormat
1. Modified to use Locale-specific decimal separator between seconds and milliseconds
2. Added protected method getFormatString() which returns either "HH:mm:ss,SSS" or "HH:mm:ss.SSS" depending on the Locale-specific decimal separator.
o.a.l.helpers.DateTimeDateFormat
1. Modified format(Date, StringBuffer, FieldPosition) to get the date portion of the date-time string at most once per day (rather than for each call to the method.).
2. Modified parse(String, ParsePosition) to actually parse a date string. This parse method is not lenient; i.e., the String must be in "dd MMM yyyy HH:mm:ssdSSS" format (where 'd' is the Locale-specific decimal seprator).
o.a.l.helpers.ISO8601DateFormat
1. Modified format(Date, StringBuffer, FieldPosition) to get the date portion of the date-time string at most once per day (rather than for each call to the method.).
2. Modified format(Date, StringBuffer, FieldPosition) to get the time portion of the date-time string from the super-class AbsoluteTimeDateFormat rather than repeating the code of the super-class.
3. Modified parse(String, ParsePosition) to actually parse a date string. This parse method is not lenient; i.e., the String must be in "yyyy-MM-dd HH:mm:ssdSSS" format (where 'd' is the Locale-specific decimal seprator).
o.a.l.lf5.util.LogFileParser
1. Modified parseDate(String) to use the updated ISO8601DateFormat.parse method to turn the logged String into a Date object.
o.a.l.lf5.viewer.FilteredLogTableModel
1. Modified getColumn(int, LogRecord) to display the date and time String using DateTimeDateFormat.format rather than Date.toString() + the long timestamp.
I hope these changes are acceptable, and if there is some other way that I should be submitting such changes then I hope I will be set on the correct path.
Mike McAngus
Associate Chief Engineer
Wendy's International
Knowledge Management
614-764-6776
Mike_McAngus@wendys.com wrote:
>The output of AbsoluteTimeDateFormat always uses a comma (",") as the
>decimal separator for fractional seconds.
>In many countries, the period (".") is used as the decimal separator.
>
>[rest deleted]
>
Re: Updating millisecond timestamps.
Posted by "Michael A. McAngus" <ma...@infinet.com>.
Ceki Gülcü wrote:
> Mike,
>
> While we are into optimizations, I think that computing the next
> occurrence of a day change is (much) faster than computing "today".
> You see what I mean?
Ceki,
I'm not sure what you mean.
If you mean that DateTimeDateFormat and ISO8601DateFormat should compare
the current DAY_OF_YEAR to the DAY_OF_YEAR in use during the previous
logging event, then yes I thought of that but there would be the
(extremely rare, but still possible) case of two logging events
occurring one year apart.
If you mean something else, please elaborate.
> By the way, have you actually tested the performance increase in your
> new classes? I would not be surprised if it was not slower than the
> existing code but maybe not...
I did not add the day tests in order to improve performance, I added
them to make it reasonable for ISO8601DateFormat to call the super-class
for the time String so that that piece of code was isolated to a single
class (I then added similar code to DateTimeDateFormat for consistency
sake, and because it seemed reasonable). The reduction in the number of
times that the Date portion of the Date-Time String was created seemed
like a side benefit.
And no, I have not done performance comparisons, but I will and I will
let you know my results.
The changes I made were prompted by the fact that the decimal separator
for AbsoluteTimeDateFormat was always a comma (,), while in many
countries of the world the decimal separator is a period (.). I found
the comma to be jarring when I looked at my test logs.
>
> At 21:12 09.06.2002 +0200, you wrote:
>
>> Mike,
>>
>> Could you please post unified diffs (diff -u)? It also be nicer to
>> have the files as attachments. Thanks, Ceki
>
I did create the files as attachments. I apologize if they don't appear
as attachments to you.
At home, I use Netscape as my email program on Windows 2000. I've just
looked at the raw email file that I sent, and the first attachment is
identified as:
--------------080408040000060707060601
Content-Type: text/plain;
name="AbsoluteTimeDateFormat.java"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="AbsoluteTimeDateFormat.java"
I suspect that the problem is the "Content-Disposition" tag. The copy
of my email that I received from the mailing list presents all the
attached files as both inline text and attachments (that may simply be
how Netscape works), but it appears that the "Content-Disposition" tag
for the attachments may be interpreted as an absolute instruction by
some email readers. I'll investigate changing this in my Netscape
configuration to whatever would tell other email programs that all
attachments are to be presented as files (as well as the email program I
use at work which seems to have made the diffs in-line and the java
files mime-encoded).
As to diffs, I created the diffs from a tool in TextPad. I will look
for a Windows program that creates "unified diffs".
Please bear with me, I'm new to Open Source collaborations.
Mike McAngus
Associate Chief Engineer
Wendy's International
Knowledge Management
614-764-6776
[rest deleted]
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Updating millisecond timestamps.
Posted by Ceki Gülcü <ce...@qos.ch>.
Mike,
While we are into optimizations, I think that computing the next occurrence
of a day change is (much) faster than computing "today". You see what I mean?
By the way, have you actually tested the performance increase in your new
classes? I would not be surprised if it was not slower than the existing
code but maybe not...
At 21:12 09.06.2002 +0200, you wrote:
>Mike,
>
>Could you please post unified diffs (diff -u)? It also be nicer to have
>the files as attachments. Thanks, Ceki
>
>At 14:45 09.06.2002 -0400, you wrote:
>>I don't know if the previous email, and this one, is the correct way for
>>non-Contributors to submit changes. I saw no responses to the previous
>>email, so if I'm doing things incorrectly, please let me know the correct
>>proceedure.
>>
>>I found two problems with my previous submission:
>>1. It broke the LogFactor5 (lf5) contributions.
>>2. It introduced a bug that I didn't notice when I was testing (I need
>>to set up JUnit, and create test cases).
>>
>>Attached are updated versions of all the files, and diff files that
>>identify the changes.
>>
>>The changes from log4j original source are as follows:
>>o.a.l.helpers.AbsoluteTimeDateFormat
>>1. Modified to use Locale-specific decimal separator between seconds and
>>milliseconds
>>2. Added protected method getFormatString() which returns either
>>"HH:mm:ss,SSS" or "HH:mm:ss.SSS" depending on the Locale-specific decimal
>>separator.
>>
>>o.a.l.helpers.DateTimeDateFormat
>>1. Modified format(Date, StringBuffer, FieldPosition) to get the date
>>portion of the date-time string at most once per day (rather than for
>>each call to the method.).
>>2. Modified parse(String, ParsePosition) to actually parse a date
>>string. This parse method is not lenient; i.e., the String must be in
>>"dd MMM yyyy HH:mm:ssdSSS" format (where 'd' is the Locale-specific
>>decimal seprator).
>>
>>o.a.l.helpers.ISO8601DateFormat
>>1. Modified format(Date, StringBuffer, FieldPosition) to get the date
>>portion of the date-time string at most once per day (rather than for
>>each call to the method.).
>>2. Modified format(Date, StringBuffer, FieldPosition) to get the time
>>portion of the date-time string from the super-class
>>AbsoluteTimeDateFormat rather than repeating the code of the super-class.
>>3. Modified parse(String, ParsePosition) to actually parse a date
>>string. This parse method is not lenient; i.e., the String must be in
>>"yyyy-MM-dd HH:mm:ssdSSS" format (where 'd' is the Locale-specific
>>decimal seprator).
>>
>>o.a.l.lf5.util.LogFileParser
>>1. Modified parseDate(String) to use the updated ISO8601DateFormat.parse
>>method to turn the logged String into a Date object.
>>
>>o.a.l.lf5.viewer.FilteredLogTableModel
>>1. Modified getColumn(int, LogRecord) to display the date and time
>>String using DateTimeDateFormat.format rather than Date.toString() + the
>>long timestamp.
>>
>>
>>I hope these changes are acceptable, and if there is some other way that
>>I should be submitting such changes then I hope I will be set on the
>>correct path.
>>
>>Mike McAngus
>
>--
>Ceki
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Updating millisecond timestamps.
Posted by Ceki Gülcü <ce...@qos.ch>.
Mike,
Could you please post unified diffs (diff -u)? It also be nicer to have the
files as attachments. Thanks, Ceki
At 14:45 09.06.2002 -0400, you wrote:
>I don't know if the previous email, and this one, is the correct way for
>non-Contributors to submit changes. I saw no responses to the previous
>email, so if I'm doing things incorrectly, please let me know the correct
>proceedure.
>
>I found two problems with my previous submission:
>1. It broke the LogFactor5 (lf5) contributions.
>2. It introduced a bug that I didn't notice when I was testing (I need to
>set up JUnit, and create test cases).
>
>Attached are updated versions of all the files, and diff files that
>identify the changes.
>
>The changes from log4j original source are as follows:
>o.a.l.helpers.AbsoluteTimeDateFormat
>1. Modified to use Locale-specific decimal separator between seconds and
>milliseconds
>2. Added protected method getFormatString() which returns either
>"HH:mm:ss,SSS" or "HH:mm:ss.SSS" depending on the Locale-specific decimal
>separator.
>
>o.a.l.helpers.DateTimeDateFormat
>1. Modified format(Date, StringBuffer, FieldPosition) to get the date
>portion of the date-time string at most once per day (rather than for each
>call to the method.).
>2. Modified parse(String, ParsePosition) to actually parse a date
>string. This parse method is not lenient; i.e., the String must be in "dd
>MMM yyyy HH:mm:ssdSSS" format (where 'd' is the Locale-specific decimal
>seprator).
>
>o.a.l.helpers.ISO8601DateFormat
>1. Modified format(Date, StringBuffer, FieldPosition) to get the date
>portion of the date-time string at most once per day (rather than for each
>call to the method.).
>2. Modified format(Date, StringBuffer, FieldPosition) to get the time
>portion of the date-time string from the super-class
>AbsoluteTimeDateFormat rather than repeating the code of the super-class.
>3. Modified parse(String, ParsePosition) to actually parse a date
>string. This parse method is not lenient; i.e., the String must be in
>"yyyy-MM-dd HH:mm:ssdSSS" format (where 'd' is the Locale-specific decimal
>seprator).
>
>o.a.l.lf5.util.LogFileParser
>1. Modified parseDate(String) to use the updated ISO8601DateFormat.parse
>method to turn the logged String into a Date object.
>
>o.a.l.lf5.viewer.FilteredLogTableModel
>1. Modified getColumn(int, LogRecord) to display the date and time String
>using DateTimeDateFormat.format rather than Date.toString() + the long
>timestamp.
>
>
>I hope these changes are acceptable, and if there is some other way that I
>should be submitting such changes then I hope I will be set on the correct
>path.
>
>Mike McAngus
>Associate Chief Engineer
>Wendy's International
>Knowledge Management
>614-764-6776
>
--
Ceki
SUICIDE BOMBING - A CRIME AGAINST HUMANITY
Sign the petition: http://www.petitiononline.com/1234567b
I am signatory number 22106. What is your number?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>