> 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 subject is simply amazing.
As we've discussed before on this list, the ISO8601 specification, an international specification, says in paragraph 5.3.1.3 (of the second draft) Representation of decimal fractions: "If necessary for a particular application a decimal fraction of hour, minute or second may be included. If a decimal fraction is included, lower order components (if any) shall be omitted and the decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0: i.e. the comma [,] or full stop [.]. Of these, the comma is the preferred sign." Identical verbiage is repeated in paragraph 5.5.3.1 Format with time-unit designators. It is somewhat unfortunate that the specification permits such latitude because it seems to violate the spirit of the spec which is to eliminate confusion arising from various popular formats and national standards of date, time, duration representation. I personally took a somewhat harder line on this subject previously and a submitted modification that simply changed the comma to a full stop character was rejected. Not having reviewed your change, it seems that it at least allows configuration of this element based on local preference? If so, then I think it might be acceptable as long as the default separator (aka preferred) is maintained as the comma in conformance to the specification and the configuration permitted is to use a full stop instead (not replacement with any arbitrary character). I would suggest that a note might be added somewhere in the documentation to warn prospective 'parsers' of log entries that the ISO8601 format might contain either a comma or full stop character in this position. Best regards, Jim Cakalic -----Original Message----- From: Michael A. McAngus [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 09, 2002 11:01 PM To: Log4J Developers List Subject: 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 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.
