https://bz.apache.org/bugzilla/show_bug.cgi?id=69817
--- Comment #10 from Mark Thomas <[email protected]> --- I now understand why you see the behaviour you describe in comment #1. SimpleDateFormat defines 'S' for milliseconds. It uses the same rule for multiple pattern letters as any other number. So if the time is ...01.123 then you'll get the following: ss.S -> 01.123 ss.SS -> 01.123 ss.SSS -> 01.123 All OK there. But if then time is 01.001 you'll get: ss.S -> 01.1 ss.SS -> 01.01 ss.SSS -> 01.001 Whoops. Zero padding has a very different meaning to the right of the decimal point and SimpleDateFormat does not take that into account. Which brings us to the AccessLogValve. It assumes that the SimpleDateFormat will only contain S or SSS so it does a replace all on "SSS" and then a replace all on "S". Which is why you see odd behaviour for SSSS. It gets treated as SSS + S. That said, even the SDF behaviour for SSSS is going to produce misleading output. Extending the first example, SDF would give: ss.SSSS -> 01.0123 which is also wrong. Just differently wrong to what Tomcat's ALV would produce. So the TL;DR is that this is a mess. SDF has issues. ALV has issues. And we want to support sub-millisecond precision. There are lots of ways we could do this. 1. Redefine S to be "fraction of second" rather than "milliseconds" when appearing after a decimal point and also redfine how ".SSSSS" patterns are displayed (i.e. correctly for the number of decimal places based on nanosecond time). Optionally, fix how "SSSSS" (no leading decimal point) is handled so that milliseconds, appropriately zero padded, are returned. 2. Introduce a Tomcat specific character "f" for "fraction of second". Optionally fix "S" to a) match SDF, or b) do the right thing after a decimal point. Something else? I'm leaning towards introducing "f" and maybe fixing "S" although given that only Chris has found the issue with ss.SSSS I'm not sure it is an issue worth fixing. Thoughts? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
