Skip to content

Navigation Menu

Sign in
Sign up

fix: timestamp format in logs - #205

Open
maxday wants to merge 6 commits into
main from
maxday/fix-156
Open

fix: timestamp format in logs #205
maxday wants to merge 6 commits into
main from
maxday/fix-156

Conversation

@maxday

@maxday maxday commented Jun 12, 2026
edited by darklight3it
Loading

Copy link
Copy Markdown
Member

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月19日T23:13:05.068Z instead of the default 2024年06月19日T23: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 commented Jun 17, 2026
edited
Loading

Copy link
Copy Markdown
Contributor

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.

Copy link
Copy Markdown
Contributor

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.

benrkia reacted with thumbs up emoji

Comment on lines +10 to +12
_DATETIME_FORMAT = "%Y-%m-%dT%H:%M:%SZ"
_DATETIME_FORMAT = "%Y-%m-%dT%H:%M:%S"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@luben luben Jun 18, 2026
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

darklight3it reacted with thumbs up emoji

benrkia commented Jun 18, 2026

Copy link
Copy Markdown

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 reacted with thumbs up emoji

This is done to support millisecond precision timestamp in the
structured logs in cloudwatch as requested in #156.
Changing directly to millisecond is a potentially breaking change, so we
agreed on supporting this environmental variable on this version of the
RIC. We'll remove the support in RIC v5, defaulting to milisecond.

Copy link
Copy Markdown
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@darklight3it darklight3it Awaiting requested review from darklight3it
@benrkia benrkia Awaiting requested review from benrkia
@M-Elsaeed M-Elsaeed Awaiting requested review from M-Elsaeed
@vip-amzn vip-amzn Awaiting requested review from vip-amzn
@anzheyazzz anzheyazzz Awaiting requested review from anzheyazzz
@rarepolz rarepolz Awaiting requested review from rarepolz
1 more reviewer
@luben luben luben left review comments
Reviewers whose approvals may not affect merge requirements

At least 2 approving reviews are required to merge this pull request.

Labels

enhancement New feature or request

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

AltStyle によって変換されたページ (->オリジナル) /