Such change could break existing clients which use timestamp in logs. I believe to be on a safe side we should add a configuration parameter controlling this behavior with default to be working with timestamp.

Unfortunately I think anyone using this library is already broken. I don't think this code is likely to be working for anyone as-is. Unless they implemented their own parser for some reason.

Here is the spec for these fields. Note that this code has been putting RFC3339 time (what happens when you implicitly call toString on an Instant) into the timestamp field. That is wrong.

Here is the code in the Google fluentd parser that parses this format. This is the original and primary intended parser for this format. Note that it doesn't know what to do if the timestamp field has a string in it. Instead it's defaulting to current time, meaning that everyone using this library with the Google Fluentd Parser is getting less accurate timestamps, representing when the parser sees the log as opposed to when the call site emitted it.

The other primary use case for this format (that I know of anyway) is GCP Serverless. Specifically this format works on App Engine Standard gen 2 and Cloud Run Managed. Internally, that code lives at go/time-is-broken. You'll note that if the field called timestamp is a string, it's ignored.

If we leave this broken default, it means this library will be broken by default for anyone trying to use it with the Google Fluentd agent, or GCP Serverless. :(

Makes sense