Re: [SUBMIT] Timezone support for date elements of pattern layout

Mark Womack wrote: >>I believe that from the various options that Mike added only the >>decimal separator and timezone should be retained. > > > Why? Why is the locale not useful in this case? I was going to wait and see exactly what was retained, and what was not. Then, if I felt strongl

Re: [SUBMIT] Timezone support for date elements of pattern layout

Mark Womack wrote: > > I have wondered about this as well for other cases. It would be useful to > have some code that searches the classpath for classes that implement a > given interface/class. But I think that this code would be very time > consuming, searching the entire classpath, inspec

Re: [SUBMIT] Timezone support for date elements of pattern layout

[EMAIL PROTECTED] wrote: > OK, I finally got a chance to review this latest set of changes. I am fine > with them. > > My only comment is that these changes were done against the 1.2 branch. As > such, after I have merged it into the current main branch, I get an error > for the ErrorHandlerTes

Re: [SUBMIT] Timezone support for date elements of pattern layout

[EMAIL PROTECTED] wrote: > Wow. Ceki, I am surprised you have not commented on this yet. Mark, Be kind. Maybe Ceki also has a real life that has kept him away from this list. I had a little extra time on my hands this past weekend, and I had been thinking about this idea since the first tim

Re: [SUBMIT] Timezone support for date elements of pattern layout

Ceki Gülcü wrote: > > Mike, > > It is very rare to have non-committers to submit patches of this > breath. Including test cases in your contribution also deserves > credit. I join Mark in expressing my thanks. Thank you Mike. > > As Mark observed these changes will go to 1.3 but possibly a

Re: [SUBMIT] Timezone support for date elements of pattern layout

Michael A. McAngus wrote: > [EMAIL PROTECTED] wrote: > >> - "Any pattern accpetible", should be "acceptible". > > > Actually, should be "acceptable". I'll fix this and submit a revised > source tonight. ... >> AbsoluteDat

Re: [SUBMIT] Timezone support for date elements of pattern layout

[EMAIL PROTECTED] wrote: > Overall, I think the changes are good. Ceki will need to review the changes > in the various date format helper classes. > > What I did was check out the latest code from the main branch, copy in the > changed files, and then reviewed them using the WinMerge tool to co

Re: [SUBMIT] Timezone support for date elements of pattern layout

Ceki Gülcü wrote: > > Mike, > > It is very rare to have non-committers to submit patches of this > breath. Including test cases in your contribution also deserves > credit. I join Mark in expressing my thanks. Thank you Mike. > > As Mark observed these changes will go to 1.3 but possibly after

Re: cvs commit: jakarta-log4j/docs SUMMARY

Oops, sorry. I meant to make this a private email to Ceki, and forgot to change the To: address. -- Cheers, Mike McAngus [EMAIL PROTECTED] Michael A. McAngus wrote: > > > [EMAIL PROTECTED] wrote: > >> ceki2002/06/28 02:09:11 >> > [snip] > >

Re: cvs commit: jakarta-log4j/docs SUMMARY

[EMAIL PROTECTED] wrote: >ceki2002/06/28 02:09:11 > [snip] > > > Mike Agnus started [4] a discussion about timezone and locale related > Yet another spelling mistake, it's Mike McAngus. > > issues in log4j date formats. James Cakalic and Mike discussed the > importance of the decim

Re: [SUBMIT] Timezone support for date elements of pattern layout

[EMAIL PROTECTED] wrote: >>1. I've added @t[timezone id], @l[language code], and @c[country >>code] suboptions. Are there any other suboptions that people want? >> > >I would make a generic method if PatternParser that will take a source >string and a target suboption character. This method

Re: [SUBMIT] Timezone support for date elements of pattern layout

omething else I should add or modify? Should I just go find something more constructive to do? What do people think? -- Cheers, Mike McAngus [EMAIL PROTECTED] Michael A. McAngus wrote: > I'm on it. > > Now, do we want to throw a scrap in James Cakalic's direction and a

Re: Small Bug + Fix in LogBrokerMonitor.java

OK, now I'm confused [sarcastic gasps from the rest of the list]. How did the original code ever work? LogBrokerMonitor is part of the lf5 contribution, and all the image files are in org/apache/log4j/lf5/viewer/images. So, are ClassLoaders able to locate resources even when the URL is inco

Re: [SUBMIT] Timezone support for date elements of pattern layout

Mark Womack wrote: >Also, what is the status of your previously submitted modifications? > I don't know. -- Cheers, Mike McAngus [EMAIL PROTECTED] -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [SUBMIT] Timezone support for date elements of pattern layout

I'm on it. Now, do we want to throw a scrap in James Cakalic's direction and add a "@d" subparameter which would allow one to arbitrarily specify the decimal separator regardless of Locale. The character could be limited to ',' and '.', or it could be opened up to the entire universe of uni

Re: [SUBMIT] Timezone support for date elements of pattern layout

Locale is the means I used to determine the decimal separator in AbsoluteTimeDateFormat (and by extension, both its subclasses). -- Cheers, Mike McAngus [EMAIL PROTECTED] Ceki Gülcü wrote: > > Hi Mike, > > How do you think the locale could influence the output of > AbsoluteTimeDateFormat or

Re: Updating millisecond timestamps.

Sorry for the delay. I finally have produced unified diffs for the modified classes. Hopefully, these will not transmit as in-line text (I added them as attachments after modifying some of my email settings). I moved the DateFormat subclasses to their o.a.l.helpers package before running the

Re: Updating millisecond timestamps.

Cakalic, James wrote: >Michael McAngus wrote: > >>>The code I submitted defaults to the comma, and it uses only the decimal >>>separators that are returned by java.text.DecimalFormatSymbols >>>(currently comma and period). >>> > >OK. And is that configurable so that one can choose the separat

Re: Updating millisecond timestamps.

Cakalic, James wrote: >>I found the comma to be jarring when I looked at my test logs. >> > >As does most of the rest of the world when viewing numbers with fractional >values separated by a period. The western bigotry (or more specifically >American bigotry) that I've encountered on this subje

Re: Updating millisecond timestamps.

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 compa

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 t