When I comparing LoggingEvent from slf4j with KLoggingEvent I can see the last important missing part - TimeStamp (Maybe ThreadName is also important, but I don't really know how threads in Native/WASM world work. Maybe current coroutine name/dispatcher is worth to add as well).
It's a proposal to add a timestamp into KLoggingEvent.
I think the Instant from https://github.com/Kotlin/kotlinx-datetime is a good candidate for this field type. I don't know your thoughts about adding dependencies to the library, though. On the other hand, it's a decent and small KMP library by JB which might do the trick as adding oneliner:
public val timestamp: Instant? = Clock.System.now(),
It might also help with date/time formatting inside Formatter.
I assume payload might be another place to put timestamp into by custom logger... I haven't really get payload field's architecture purpose yet. But it's still worth to discuss separated field anyway, as using Map with String key for such popular field might cause performance issues (as well as adding Clock.System.now() in every logging event. I haven't really measured its performance, but I assume it's fast and not a problem).
When I comparing
LoggingEvent
from slf4j withKLoggingEvent
I can see the last important missing part - TimeStamp (Maybe ThreadName is also important, but I don't really know how threads in Native/WASM world work. Maybe current coroutine name/dispatcher is worth to add as well).It's a proposal to add a timestamp into
KLoggingEvent
.I think the
Instant
from https://github.com/Kotlin/kotlinx-datetime is a good candidate for this field type. I don't know your thoughts about adding dependencies to the library, though. On the other hand, it's a decent and small KMP library by JB which might do the trick as adding oneliner:It might also help with date/time formatting inside
Formatter
.I assume
payload
might be another place to put timestamp into by custom logger... I haven't really getpayload
field's architecture purpose yet. But it's still worth to discuss separated field anyway, as using Map withString
key for such popular field might cause performance issues (as well as addingClock.System.now()
in every logging event. I haven't really measured its performance, but I assume it's fast and not a problem).