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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
