Resolving Ambiguous DST Times for Twilio Message Scheduling and TaskRouter Worker Availability

Answer

The standard (later) offset—i.e., the IANA fold flag set to 1 (standard time)—should be used when converting ambiguous local times to UTC for Twilio send_at and TaskRouter worker scheduling.

Why

During DST fallback the same wall‑clock time occurs twice: first with a daylight offset (fold 0) and then with a standard offset (fold 1). The IANA tz database marks the later occurrence as fold 1. Industry best practice (RFC 5545, ICU, java.time, Python PEP 495, Noda Time) is to treat the later (standard) occurrence as the default for future‑scheduled events, because the daylight offset will have already ended.

Steps to apply

1. Ensure your runtime uses a current IANA tzdata release (e.g., 2024a or newer).
2. Convert the ambiguous local time to a ZonedDateTime (or equivalent) using the zone identifier and explicitly selecting the standard offset (fold = 1). In Java: ZonedDateTime.of(local, zone, ZoneOffset.ofHours(-5)) for America/New_York after the fallback.
3. Extract the UTC instant from the ZonedDateTime and pass it as an ISO‑8601 timestamp to Twilio’s send_at parameter.
4. When configuring TaskRouter workers, store the IANA zone string (e.g., America/New_York) and let TaskRouter handle UTC conversion; do not supply ambiguous local times directly.
5. Validate the conversion with a unit test that asserts the UTC result equals 2026-11-01T06:30Z for the example 2026‑11‑01 02:30 America/New_York.

Verification

• Check Twilio response: a successful send_at returns a Message SID; a 400 Bad Request with “Invalid send_at timestamp” means the UTC time was malformed or in the past.
• Query TaskRouter via GET /Workers/{Sid} and confirm the Available flag matches the expected UTC window.
• Run zdump -v America/New_York | grep 2026 in the container to verify the transition instant and the standard offset used.