https://bz.apache.org/bugzilla/show_bug.cgi?id=69817
--- Comment #12 from Christopher Schultz <[email protected]> --- (In reply to Mark Thomas from comment #10) > Zero padding has a very different meaning to the right of the > decimal point and SimpleDateFormat does not take that into account. :( > 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. I think it's fairly important to ensure that existing date formats continue to work, so "S" and "SSS" need to continue to mean "milliseconds". Above and beyond that, I think we have a lot of latitude. What would "s.f" give us? What about "s.ff" and so on? I think a reasonable expectation of a user would be that the more "f"s you have there, the more precision you'd get.S if you had 1.23456789 seconds, each "f" you gave would give you one more digit from that string, possibly rounding the final digit if we really wanted to. It would be a little unexpected to request a precision of 100-µs but there isn't a particular reason not to support it. If we can support an arbitrary number of "t"s, why not support an arbitrary number of "S"s? It would make the code more consistent than it is today and doesn't introduce a new (completely) non-standard conversion character. The only thing it would break is current installations where the number of "S" conversion characters is neither 1 nor 3. But those were already lying to their users, so fixing it seems like a net positive to me. -- 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]
