UTC Offset Choice for Twilio Scheduling & TaskRouter

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

0 reputation · 13 Jun 2023, 03:25 UTC

66.8K views0

Developers must convert regional local times to UTC for Twilio message scheduling and TaskRouter worker availability.

Twilio's send_at parameter requires an ISO 8601 UTC timestamp and TaskRouter worker timezone strings must be valid IANA zones; during DST fallback the same local time occurs twice, requiring a decision on which offset to apply.

Which UTC offset (standard or daylight) should be used when converting ambiguous local times to UTC for Twilio send_at and TaskRouter worker scheduling?

2,947 following

Keep exploring this topic

AT TIME ZONE selects earlier offset during ambiguous DST fall-back without disambiguation option

SQL Server's AT TIME ZONE picks the earlier offset during DST fall-back ambiguous hours with no way to choose the later offset. No built-in function lists all valid offsets for a local time, and results depend on OS patch level.

SPSS datetime values lack timezone metadata: how to handle regional conversions?

SPSS stores datetime values as seconds since 1582‑10‑14 with no timezone metadata. Users must manually apply UTC offsets or use extensions to handle DST transitions. How can one convert timezone‑aware timestamps into SPSS datetimes while preserving the instant and avoiding ambiguous times?

Twilio Studio flow rollback leaves execution state ambiguous

Unclear how Twilio Studio handles flow‑level variables and execution state during a version rollback while existing executions continue.

DateTime::TimeZone ambiguous local time resolution during DST fallback

How should DateTime::TimeZone handle ambiguous local times during DST fallback when no explicit disambiguation is provided?

Twilio's send_at and TaskRouter accept only UTC timestamps and IANA zone strings respectively — neither exposes a DST-disambiguation parameter. During fallback transitions (e.g., 2026-11-01 01:30 America/New_York), most standard libraries (Java java.time, Python zoneinfo, Node Intl.DateTimeFormat) default to the earlier offset (EDT, UTC-4) unless you explicitly request the later one (EST, UTC-5).

To guarantee the standard-time interpretation, convert in application code with an explicit policy before calling Twilio:

Python: dt.replace(fold=1) then .astimezone(timezone.utc)
Java: ZonedDateTime.ofInstant(local, ZoneOffsetTransitionRule.STANDARD)
Go: time.LoadLocation then time.Date(..., 0, loc) with fold=1 via time.Time.In

Test against known fallback dates (e.g., first Sunday in November for US zones) and verify the IANA tzdata version in your runtime (zdump -v or equivalent) to avoid silent drift from rule changes.

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

0 answers

Your perspective belongs here.

1 question comment