Skip to content

ISO 8601 timestamps emitted with different precision in Python vs Node #20

Description

@AndresL230

ISO 8601 timestamps emitted with different precision in Python vs Node

Severity: Medium
Affected repos: middleware-python, middleware-node, api
Component boundary: middleware → API telemetry

Symptom

  • Python emits datetime.now(timezone.utc).isoformat() → microsecond precision with +00:00 suffix: "2026-05-13T14:30:45.123456+00:00".
  • Node emits new Date().toISOString() → millisecond precision with Z suffix: "2026-05-13T14:30:45.123Z".

The API stores windowStart and windowEnd and later compares across SDKs in rollups. Sorting and grouping still work (ISO 8601 collation), but anyone who joins on equality, parses with a fixed format, or computes deltas across SDKs has to handle the shape difference.

Evidence

  • middleware-python/recost/_aggregator.pydatetime.now(timezone.utc).isoformat().
  • middleware-node/src/core/aggregator.tsnew Date().toISOString().

Impact

  • Inconsistent wire format. Cosmetic in most analyses; potentially a sharp edge in any future code that does exact-string compare or parses with a tighter format.

Fix recommendation

Normalize both to millisecond-precision Z format (matches Node, which is more compact):

# Python
def _iso_now() -> str:
    return datetime.now(timezone.utc).isoformat(timespec="milliseconds").replace("+00:00", "Z")

Verification

  • Python and Node SDKs emit identical timestamp string formats for the same instant (within ms).

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions