[GH-ISSUE #438] Fix the "datetime" field/add "timestamp" field #153

New issue

Closed

opened 2026-03-04 02:12:40 +03:00 by kerem · 4 comments

kerem commented

2026-03-04 02:12:40 +03:00

Owner

Originally created by @giannello on GitHub (Oct 21, 2014).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/438

As per current implementation, monolog is not able to provide high-resolution timestamps for logs, because of the use of the DateTime object. Also - despite what the v1.3.0 changelog states (Support for millisecond in timestamps) - the feature is actually not more than a mock and the test case itself is not optimal, as it tests an edge case.
Right now, the only way to make sure logs coming out from monolog are accurate is to rely on the output sequence of the messages. While this case is acceptable when using file/stdout output, it's not valid anymore when outputting to an AMQP broker for later consumption.
In this case, as AMQP does not guarantee an ordered delivery, any indexer (InfluxDB, in our current implementation) will need a higher-resolution timestamp to make sure the log messages can be indexed/viewed in the correct order.
As log messages are not more than description of events in time, the best solution would be to just store the unix timestamp with microseconds, and let the presentation layer convert them to the appropriate date/time format the user needs.

Originally created by @giannello on GitHub (Oct 21, 2014). Original GitHub issue: https://github.com/Seldaek/monolog/issues/438 As per current implementation, monolog is not able to provide high-resolution timestamps for logs, because of the use of the DateTime object. Also - despite what the v1.3.0 changelog states (Support for millisecond in timestamps) - the feature is actually not more than a mock and the test case itself is not optimal, as it tests an edge case. Right now, the only way to make sure logs coming out from monolog are accurate is to rely on the output sequence of the messages. While this case is acceptable when using file/stdout output, it's not valid anymore when outputting to an AMQP broker for later consumption. In this case, as AMQP does not guarantee an ordered delivery, any indexer (InfluxDB, in our current implementation) will need a higher-resolution timestamp to make sure the log messages can be indexed/viewed in the correct order. As log messages are not more than description of events in time, the best solution would be to just store the unix timestamp with microseconds, and let the presentation layer convert them to the appropriate date/time format the user needs.

kerem closed this issue

2026-03-04 02:12:40 +03:00

kerem commented

2026-03-04 02:12:41 +03:00

Author

Owner

@Seldaek commented on GitHub (Oct 21, 2014):

That might have been a better approach but it'd be a BC break at this point. Can you explain in more details why the current DateTime solution does not work though? As far as I know if you do format it correctly on output you will get 1/10th of millisecond precision (i.e. 4 digits after the comma, which is what microtime() gives us).

@Seldaek commented on GitHub (Oct 21, 2014): That might have been a better approach but it'd be a BC break at this point. Can you explain in more details why the current DateTime solution does not work though? As far as I know if you do format it correctly on output you will get 1/10th of millisecond precision (i.e. 4 digits after the comma, which is what microtime() gives us).

kerem commented

2026-03-04 02:12:41 +03:00

Author

Owner

@giannello commented on GitHub (Oct 21, 2014):

well, with the current approach, serializing the DateTime object to JSON will not guarantee the right precision - but this is being addressed in #402
The problem with the formatting is actually related to the way php handles rounding floats when they are printed:

var_dump(microtime(true));
double(1413889351.4628)

ini_set('precision', 16);
var_dump(microtime(true));
double(1413889351.462944)

any higher precision will result in zeroes added after the microsecond value.

A possible, non-breaking solution would be to add a config parameter that enables adding a "timestamp" field, and that field - to avoid arbitrary rounding - should be a string and not a float

var_dump(sprintf('%.6F', microtime(true)));
string(17) "1413889075.741188"

Not the best way, as a proper numeric type should be used, but consistent.
I'm working on a fix in my fork, might be able to submit it today.

@giannello commented on GitHub (Oct 21, 2014): well, with the current approach, serializing the DateTime object to JSON will not guarantee the right precision - but this is being addressed in #402 The problem with the formatting is actually related to the way php handles rounding floats when they are printed: ``` php var_dump(microtime(true)); double(1413889351.4628) ``` ``` php ini_set('precision', 16); var_dump(microtime(true)); double(1413889351.462944) ``` any higher precision will result in zeroes added after the microsecond value. A possible, non-breaking solution would be to add a config parameter that enables adding a "timestamp" field, and that field - to avoid arbitrary rounding - should be a string and not a float ``` php var_dump(sprintf('%.6F', microtime(true))); string(17) "1413889075.741188" ``` Not the best way, as a proper numeric type should be used, but consistent. I'm working on a fix in my fork, might be able to submit it today.

kerem commented

2026-03-04 02:12:41 +03:00

Author

Owner

@giannello commented on GitHub (Oct 21, 2014):

Not the perfect solution - the timestamp generated will be slightly (milliseconds) different from the real timestamp of the message ($date->format('U.u') returns a value with 0 microseconds) - but still better than nothing, and it's fully backwards-compatible

@giannello commented on GitHub (Oct 21, 2014): Not the perfect solution - the timestamp generated will be slightly (milliseconds) different from the real timestamp of the message ($date->format('U.u') returns a value with 0 microseconds) - but still better than nothing, and it's fully backwards-compatible

kerem commented

2026-03-04 02:12:41 +03:00

Author

Owner

@Seldaek commented on GitHub (May 26, 2016):

As far as I can tell this was fixed by https://github.com/Seldaek/monolog/pull/793 - in 2.0 if you enable microsecond precision then json-serialized datetime objects will have full precision.

@Seldaek commented on GitHub (May 26, 2016): As far as I can tell this was fixed by https://github.com/Seldaek/monolog/pull/793 - in 2.0 if you enable microsecond precision then json-serialized datetime objects will have full precision.