[ParidelPooya]

Summary

Every Durable Execution Telemetry record timestamp now uses one format: YYYY-MM-DDTHH:MM:SS.sssZ. The fraction always has exactly 3 digits. The suffix is always Z. JavaScript's Date.prototype.toISOString() writes the same format.

The change covers emittedAt, startTime and endTime on the record, and startTime and endTime on each operation. One helper, _format_record_timestamp() in plugin.py, now produces all of them. It converts the time to UTC. It then calls isoformat(timespec="milliseconds"), which truncates microseconds. It does not round.

Example: 2026-10-23T18:42:40.784119Z becomes 2026-10-23T18:42:40.784Z. A time with 0 microseconds was 2026-10-23T18:42:40Z. It is now 2026-10-23T18:42:40.000Z.

Why

1. A deployed test ran the JS, Python and Java exporters on the same workflow.
2. Python wrote 6 fraction digits, for example 2026-10-23T18:42:40.784119Z.
3. Python's isoformat() writes no fraction when microseconds are 0.
4. JS always writes 3 digits. Java writes 3 or 9.
5. DynamoDB, CloudWatch Logs Insights, and string columns compare these values as text.
6. Text order equals time order only when every value has the same width.
7. In the test, …40Z sorted after …40.500Z.
8. In the test, endtime >= '2026-10-23T18:42:46Z' excluded all 7 records that ended in that second.
9. So all SDKs will write one fixed-width format. JS already writes it.

Unchanged

• A datetime inside a user's operation result still becomes isoformat(). That value is user data, not a record timestamp.
• The LambdaLogExporter envelope timestamp already had 3 digits.
• exporters/_common.py parsing already accepts the new format.

Other edits

• README: states the timestamp format next to the record schema description.
• truncation.py and otel_exporter.py: comments now describe the fixed-width format.
• test_plugin.py: two assertions pinned 2026-01-01T00:00:00Z. They now expect 2026-01-01T00:00:00.000Z.
• New tests/test_timestamp_format.py: asserts ^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}Z$ for all 5 record timestamp fields of an emitted record. It covers 0 microseconds (.000Z), truncation (784119 µs gives .784Z, 999999 µs gives .999Z), and a +05:30 aware datetime converted to UTC.

Testing

• pytest -n 8 packages/aws-durable-execution-sdk-python-telemetry-exporter/tests: 282 passed, 1 failed. The failure is test_package_metadata.py::test_public_version_matches_installed_stable_release. It fails locally because the installed package metadata is stale. The change does not touch it.
• mypy on the telemetry exporter src and tests: no issues.
• hatch fmt --check in the telemetry exporter package: passed.
• lintcommit.py on the commit: passed.

Java gets the same change in a sibling PR. JS already writes this format.

emittedAt strictly increases within one invocation

emittedAt has millisecond precision. In on-change mode, one invocation can build two records in the same millisecond. The SQS FIFO deduplication id is executionArn:emittedAt. The default DynamoDB sort key is emittedAt. So equal values made SQS drop a message and made DynamoDB overwrite an item. So commit e06600a makes emittedAt strictly increase within one plugin instance, which serves one invocation. Each record takes the current time, truncated to milliseconds, when it is later than the last emittedAt. Otherwise it takes the last value plus 1 millisecond. The value is chosen during snapshot admission, under _lock. JS uses the same rule: aws/aws-durable-execution-sdk-js#1071. New tests in tests/test_timestamp_format.py freeze the clock and expect .123Z, .124Z, .125Z for RUNNING, RUNNING and SUCCEEDED.

[github-actions]

Codex AI review

One P2 remains at packages/aws-durable-execution-sdk-python-telemetry-exporter/src/aws_durable_execution_sdk_python_telemetry_exporter/plugin.py:513: emission identities can collide across resumed invocations. Tests were not executed, per the read-only review constraint.

Reviewed commit 1c6664fa45e7f13a60bc660eb71638df76610722. Workflow run