Scheduled Messaging API: UTC SendAt timestamps ignore local DST transitions

Answer

Twilio’s Programmable Messaging API treats the SendAt value as a fixed UTC timestamp; it does not apply any time‑zone or daylight‑saving conversion. Therefore, if you compute the UTC value using a static offset or ignore upcoming DST rule changes, the message may be delivered an hour early or late when the target region’s clocks shift.

Confirmed facts

• The API documentation specifies that SendAt must be an ISO‑8601 UTC timestamp and all returned timestamp fields are in UTC.
• Twilio does not accept a time‑zone identifier or local‑time value, and there is no public announcement of a future time‑zone parameter or automatic DST adjustment.
• Using a fixed offset (e.g., -05:00) instead of a named IANA zone will break when the region enters or leaves daylight saving time.

Recommended steps for this case

1. Obtain the IANA time zone identifier for the recipient’s location (e.g., America/New_York).
2. At the moment you schedule the message, convert the desired local delivery time to UTC using an up‑to‑date time‑zone library (such as moment‑timezone, date‑fns‑tz, or Java’s ZoneId).
3. Store the IANA zone together with the scheduled message so you can re‑run the conversion if government DST rules change before the send time.
4. If you need to reschedule or verify the timing, repeat the conversion with the latest zone data and update SendAt accordingly.
5. If you cannot reschedule, accept that the fixed UTC timestamp may cause an off‑by‑one‑hour delivery during a DST transition.

Missing diagnostic detail

To confirm whether the above steps are sufficient, please let me know: do you have access to the IANA time zone identifier for the target region, or are you only working with a fixed UTC offset?