fix: timestamp format in logs

[maxday]

Issue #, if available:

#156

Description of changes:

Adds opt-in millisecond timestamp precision for JSON structured logs. When AWS_LAMBDA_LOG_TIMESTAMP_PRECISION=milliseconds is set, timestamps are formatted as 2024-06-19T23:13:05.068Z instead of the default 2024-06-19T23:13:05Z.

Key changes:

• Shared _format_timestamp() function used by both JsonFormatter and bootstrap.py error logging, ensuring consistent output.
• Default remains second precision — no breaking change.
• TODO and version-gate test to make milliseconds the default in v5.0.
• Unit tests covering both precision modes.
• Container-image demo (demo/) for end-to-end validation.

Target (OCI, Managed Runtime, both):

Both

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[darklight3it]

From experience this kind of changes can be very dangerous. For multiple reasons.

I'm not that worried about CloudWatch compatibility (we can always ask @luben for that)

Imagine a customer creating a script to analyze some logs and expecting a strict format, or worse blindly exporting the logs to another database with a strict schema.

My idea here is that we should opt-in the new format, so the customer won't be surprised by the change.

[darklight3it]

Also I think this is also highlighting a design flaw. The RIC should not be concerned with the time format.

It should flush to the sink the biggest possible epoch and CW should do the conversion to human readable time.

[luben]

Is this used by any other code? I nothing else is using it we can just append .%f here.

[luben]

I think it would be safer to leave that string and just use another format string in the formatTime override

[benrkia]

Also I think this is also highlighting a design flaw. The RIC should not be concerned with the time format.

I agree, can we consider that in a major version change?

[darklight3it]

Did some manual integration tests for that. Here the results.

=== Invoking ric-timestamp-demo-seconds (default - seconds precision) ===
START RequestId: 08362ce1-8885-4a72-9909-da5fffe1a480 Version: $LATEST
{"timestamp": "2026-06-25T22:14:30Z", "level": "INFO", "message": "First log message", "logger": "root", "requestId": "08362ce1-8885-4a72-9909-da5fffe1a480"}
{"timestamp": "2026-06-25T22:14:30Z", "level": "INFO", "message": "Second log message", "logger": "root", "requestId": "08362ce1-8885-4a72-9909-da5fffe1a480"}
{"timestamp": "2026-06-25T22:14:30Z", "level": "WARNING", "message": "A warning with sub-second timing", "logger": "root", "requestId": "08362ce1-8885-4a72-9909-da5fffe1a480"}
END RequestId: 08362ce1-8885-4a72-9909-da5fffe1a480
REPORT RequestId: 08362ce1-8885-4a72-9909-da5fffe1a480  Duration: 2.46 ms       Billed Duration: 460 ms Memory Size: 128 MB    Max Memory Used: 35 MB   Init Duration: 456.96 ms

=== Invoking ric-timestamp-demo-milliseconds (milliseconds precision) ===
START RequestId: fba920c6-24e8-4380-a34c-e7eff76c6f9e Version: $LATEST
{"timestamp": "2026-06-25T22:14:34.512Z", "level": "INFO", "message": "First log message", "logger": "root", "requestId": "fba920c6-24e8-4380-a34c-e7eff76c6f9e"}
{"timestamp": "2026-06-25T22:14:34.513Z", "level": "INFO", "message": "Second log message", "logger": "root", "requestId": "fba920c6-24e8-4380-a34c-e7eff76c6f9e"}
{"timestamp": "2026-06-25T22:14:34.513Z", "level": "WARNING", "message": "A warning with sub-second timing", "logger": "root", "requestId": "fba920c6-24e8-4380-a34c-e7eff76c6f9e"}
END RequestId: fba920c6-24e8-4380-a34c-e7eff76c6f9e
REPORT RequestId: fba920c6-24e8-4380-a34c-e7eff76c6f9e  Duration: 2.63 ms       Billed Duration: 358 ms Memory Size: 128 MB    Max Memory Used: 35 MB   Init Duration: 355.10 ms