Recipient timezone respected for send time

Scheduling all sends in server UTC means a "send at 9am" step reaches a contact in Tokyo at 9pm and a contact in London at 8am in summer, 9am in winter. Open rates for email campaigns vary by as much as 30% based on local time of delivery — sending into the wrong timezone is a measurable conversion loss, not a cosmetic issue. iso-25010:2011 functional-suitability.functional-correctness treats this as a functional accuracy defect: the system executes the correct action (sends the email) at the wrong time (server timezone rather than recipient timezone), producing a systematically degraded outcome for any globally distributed contact list.

Store a timezone field on contact records (IANA format, e.g. 'America/New_York') and use it to convert the step's preferred local send hour to a UTC timestamp before scheduling.

import { zonedTimeToUtc, utcToZonedTime } from 'date-fns-tz'

function computeSendTime(delayDays: number, preferredHour: number, contactTimezone: string): Date {
  const now = new Date()
  const nowInContactTz = utcToZonedTime(now, contactTimezone)

  const targetInContactTz = new Date(nowInContactTz)
  targetInContactTz.setDate(targetInContactTz.getDate() + delayDays)
  targetInContactTz.setHours(preferredHour, 0, 0, 0)

  return zonedTimeToUtc(targetInContactTz, contactTimezone)
}

Fall back to a sensible default timezone (e.g. 'America/New_York') when a contact has no timezone set — do not silently use server UTC. Libraries like date-fns-tz, Luxon, or dayjs with the timezone plugin all handle DST transitions correctly.