The main motivation to have microsecond-precision timestamps in logs is for detailed debugging and performance analysis.
Other Java-based servers, such as WildFly, are already considering support for microsecond-level logging - https://stackoverflow.com/users/152794/james-r-perkins Could this be considered, and we would like to know if, similar to WildFly, there are any plans to implement microsecond-precision logging in Tomcat. If there is a limitation with tomcat9 and below, could it be considered for tomcat 10 and above. Regards, Poojashree Prakash On Fri, Sep 12, 2025 at 8:38 PM Harri Pesonen <[email protected]> wrote: > java.lang.Instant comes with Java 8 but there it does not have microsecond > precision yet (it can store even nanoseconds but they are all zeros). > > Personally I don't see much reason for microsecond precision in logs > either, but perhaps it could be an option. > > -Harri > > -----Original Message----- > From: Mark Thomas <[email protected]> > Sent: perjantai 12. syyskuuta 2025 17.44 > To: Tomcat Users List <[email protected]> > Subject: Re: Support for microsecond precision in timestamps (Tomcat > 9.0.108 / 10.1.44) > > On 12/09/2025 13:00, Poojashree Prakash wrote: > > +1 > > Java9 and above supports precision logging - timestamp - Current time > > in microseconds in java - Stack Overflow > > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsta > > ckoverflow.com%2Fquestions%2F1712205%2Fcurrent-time-in-microseconds-in > > -java&data=05%7C02%7Charri.pesonen%40sinch.com%7C668025699f024c646b6f0 > > 8ddf20af08e%7C3b518aae89214a7b8497619d756ce20e%7C0%7C0%7C6389328510157 > > 79455%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat > > a=33veKYxAmaT4XVPSo65DLVb7T31t%2BZaujXAG6HHqNjk%3D&reserved=0> > > Also considering - Apache Tomcat(r) - Which Version Do I Want? > > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftom > > cat.apache.org%2Fwhichversion.html&data=05%7C02%7Charri.pesonen%40sinc > > h.com%7C668025699f024c646b6f08ddf20af08e%7C3b518aae89214a7b8497619d756 > > ce20e%7C0%7C0%7C638932851015805837%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1 > > hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=qSqG%2BLOpgY1iZSBhK2PmGaQ1lp0i2m2O6wGCU > > HBjIWM%3D&reserved=0> > > > > tomcat11 Supports java 17 and above > > tomcat10 Support java 11 and above > > tomcat9 Supports java 8 and above > > So, does Tomcat provide any way to log access timestamps with > > microsecond precision? > > If not, is there an upcoming plan to enable true microsecond precision > > in timestamps for Tomcat logs? > > I stand corrected. > > There are no currently plans for microsecond precision in timestamps for > either logs or the access log. > > There are a number of things any implementation would need to take account > of: > > - Tomcat 9 has a minimum Java version of 8 so Instant might not be > available for log messages. It is likely some form of JreCompat based > solution would be required for Tomcat 9 > > - Converting the timestamps to strings would need some thought. The > timestamp to String conversions in Tomcat are heavily optimised for > performance. Work would be required to determine if that were still > necessary and, if it were, to develop appropriate solutions > > - The access log valve implementations would need to be converted to use > Instant. A bigger issue is the API uses milliseconds. The API and > configuration would need to be updated in a backwards compatible way > for this to be available on anything earlier than Tomcat 12. > > All of which begs the question. Why? What is it that you are trying to do > that you can't do with the current millisecond logs and microseconds for > request processing time? > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
