TTL silent non-deletion with millisecond epoch DynamoDB Time To Live

A design needs items to expire at a consistent local midnight in America/New_York and to remain sortable for range queries across daylight saving time transitions.

DynamoDB provides no native datetime or timezone type. Temporal values are stored as String ISO 8601, Number epoch, or decomposed types. TTL evaluates a Number attribute as UTC Unix epoch seconds only; PartiQL and Query/Scan filter expressions have no timezone conversion functions and treat string and number attributes as opaque ordered values. DynamoDB Streams and PITR timestamps are UTC, and cross-region replication preserves stored values verbatim with no timezone metadata.

Storing local wall-clock time with an IANA zone identifier preserves display intent but breaks lexicographic sort and filter semantics on a GSI keyed by string, especially with mixed offsets. Normalizing all writes to UTC preserves sort and TTL correctness but pushes all presentation-timezone conversion to the read path. DynamoDB provides no validation or tooling to enforce consistency between a UTC canonical attribute and a local display attribute.

Is TTL expected to accept epoch milliseconds for expiration, or is epoch seconds the only supported unit? How should a table be modeled to support both correct TTL evaluation in UTC and correct chronological ordering for queries that must respect DST transitions? What guarantees exist for sort order of ISO 8601 strings with differing offsets on a Global Secondary Index sort key?