Microseconds to error log

Description

Hi there,

Not sure if this is the right place to discuss the topic. Please, guide me to the proper place if this needs to be re-directed.

We have quite a high-loaded environment and we really want to see timestamps containing microseconds in our logs. It is easy to do for our custom logger but error messages from the PHP itself narrowed down to seconds (I'm talking about method php_log_err_with_severity()

In our repository, we have a hacky patch that adds microsecs in this log as well. Unfortunately, such a solution is not really a good approach to looking into the future.

I wanted to adopt our patch to share it with the community and potentially merge it into upstream but stumbled upon the fact that it isn't really straightforward to format a date with microseconds using the standard API available for an extension.

Basically, I found a couple of options:

1. We can instantiate a DateTime object and call DateTime::format(). It looks working but it makes the logging function way more complicated and potentially heavy

2. date_format works directly with timelib_time and can properly handle microsecs but it is hidden inside ext/date/php_date.c, Not really sure if it's a good idea to make it public

3. In theory, it is possible to add one more parameter to php_format_date but it'll break all the existing code. The change of signature doesn't look like a good option. However, we might be able to introduce another function if we want to encapsulate work with timelib_time within the ext/date.

Looking into the future, probably we would like to have this format configurable, if so it looks easy to do but still I can't see an easy way to handle the microseconds issue.

Could you please help me to find the right way and share your thoughts about this topic (maybe there are strong objections against such a change)?

Comienza leyendo php_log_err_with_severity() en main/main.c y el código de formateo de fechas en ext/date/php_date.c. Compara los enfoques disponibles descritos en el issue y determina qué API o diseño upstream es aceptable sin romper los callers existentes. Se considera terminado cuando el alcance y el camino de implementación para las marcas de tiempo de microsegundos del registro de errores estén acordados y sean aplicables.