This video by Henryk Brzozowski walks you through how to prepare for handling time zones when building Voice Agents with Make.com and Figma. You’ll learn key vocabulary, core concepts, setup tips, and practical examples to help you avoid scheduling and conversion pitfalls.
You can follow a clear timeline: 0:00 start, 0:33 Figma, 9:42 Make.com level 1, 15:30 Make.com level 2, and 24:03 wrap up, so you know when to watch the segments you need. Use the guide to set correct time conversions, choose reliable timezone data, and plug everything into Make.com flows for consistent voice agent behavior.
Vocabulary and core concepts you must know
You need a clear vocabulary before building time-aware voice agents. Time handling is full of ambiguous terms and tiny differences that matter a lot in code and conversation. This section gives you the core concepts you’ll use every day, so you can design prompts, store data, and debug with confidence.
Definition of time zone and how it differs from local time
A time zone is a region where the same standard time is used, usually defined relative to Coordinated Universal Time (UTC). Local time is the actual clock time a person sees on their device — it’s the time zone applied to a location at a specific moment, including DST adjustments. You should treat the time zone as a rule set and local time as the result of applying those rules to a specific instant.
UTC, GMT and the difference between them
UTC (Coordinated Universal Time) is the modern standard for civil timekeeping; it’s precise and based on atomic clocks. GMT (Greenwich Mean Time) is an older astronomical term historically used as a time reference. For most practical purposes you can think of UTC as the authoritative baseline. Avoid mixing the two casually: use UTC in systems and APIs to avoid ambiguity.
Offset vs. zone name: why +02:00 is not the same as Europe/Warsaw
An offset like +02:00 is a static difference from UTC at a given moment, while a zone name like Europe/Warsaw represents a region with historical and future rules (including DST). +02:00 could be many places at one moment; Europe/Warsaw carries rules for DST transitions and historical changes. You should store zone names when you need correct behavior across time (scheduling, historical timestamps).
Timestamp vs. human-readable time vs. local date
A timestamp (instant) is an absolute point in time, often stored in UTC. Human-readable time is the formatted representation a person sees (e.g., “3:30 PM on June 5”). The local date is the calendar day in a timezone, which can differ across zones for the same instant. Keep these distinctions in your data model: timestamps for accuracy, formatted local times for display.
Epoch time / Unix timestamp and when to use it
Epoch time (Unix timestamp) counts seconds (or milliseconds) since 1970-01-01T00:00:00Z. It’s compact, timezone-neutral, and ideal for storage, comparisons, and transmission. Use epoch when you need precision and unambiguous ordering. Convert to zone-aware formats only when presenting to users.
Locale and language vs. timezone — they are related but separate
Locale covers language, date/time formats, number formats, and cultural conventions; timezone covers clock rules for location. You may infer a locale from a user’s language preferences, but locale does not imply timezone. Always allow separate capture of each: language/localization for wording and formatting, timezone for scheduling accuracy.
ABBREVIATIONS and ambiguity (CST, IST) and why to avoid them
Abbreviations like CST or IST are ambiguous (CST can be Central Standard Time or China Standard Time; IST can be India Standard Time or Irish Standard Time). Avoid relying on abbreviations in user interaction and in data records. Prefer full IANA zone names or numeric offsets with context to disambiguate.
Time representations and formats to handle in Voice Agents
Voice agents must accept and output many time formats. Plan for both machine-friendly and human-friendly representations to minimize user friction and system errors.
ISO 8601 basics and recommended formats for storage and APIs
ISO 8601 is the standard for machine-readable datetimes: e.g., 2025-12-20T15:30:00Z or 2025-12-20T17:30:00+02:00. For storage and APIs, use either UTC with the Z suffix or an offset-aware ISO string that includes the zone offset. ISO is unambiguous, sortable, and interoperable — make it your default interchange format.
Common spoken time formats and parsing needs (AM/PM, 24-hour)
Users speak times in 12-hour with AM/PM or 24-hour formats, and you must parse both. Also expect natural variants (“half past five”, “quarter to nine”, “seven in the evening”). Your voice model or parsing layer should normalize spoken phrases into canonical times and ask follow-ups when the phrase is ambiguous.
Date-only vs time-only vs datetime with zone information
Distinguish the three: date-only (a calendar day like 2025-12-25), time-only (a clock time like 09:00), and datetime with zone (2025-12-25T09:00:00Europe/Warsaw). When users omit components, ask clarifying questions or apply sensible defaults tied to context (e.g., assume next occurrence for time-only prompts).
Working with milliseconds vs seconds precision
Some systems and integrations expect seconds precision, others milliseconds. Voice interactions rarely need millisecond resolution, but calendar APIs and event comparisons sometimes do. Keep an internal convention and convert at boundaries: store timestamps with millisecond precision if you need subsecond accuracy; otherwise seconds are fine.
String normalization strategies before processing user input
Normalize spoken or typed time strings: lowercase, remove filler words, expand numerals, standardize AM/PM markers, convert spelled numbers to digits, and map common phrases (“noon”, “midnight”) to exact times. Normalization reduces parser complexity and improves accuracy.
Formatting times for speech output for different locales
When speaking back times, format them to match user locale and preferences: in English locales you might say “3:30 PM” or “15:30” depending on preference. Use natural language for clarity (“tomorrow at noon”, “next Monday at 9 in the morning”), and include timezone information when it matters (“3 PM CET”, or “3 PM in London time”).
IANA time zone database and practical use
The IANA tz database (tzdb) is the authoritative source for timezone rules and names; you’ll use it constantly to map cities to behaviors and handle DST reliably.
What IANA tz names look like (Region/City) and why they matter
IANA names look like Region/City, for example Europe/Warsaw or America/New_York. They encapsulate historical and current rules for offsets and DST transitions. Using these names prevents you from treating timezones as mere offsets and ensures correct conversion across past and future dates.
When to store IANA names vs offsets in your database
Store IANA zone names for user profiles and scheduled events that must adapt to DST and historical changes. Store offsets only for one-off snapshots or when you need to capture the offset at booking time. Ideally store both: the IANA name for rules and the offset at the event creation time for auditability.
Using tz database to handle historical offset changes
IANA includes historical changes, so converting a UTC timestamp to local time for historical events yields the correct past local time. This is crucial for logs, billing, or legal records. Rely on tzdb-backed libraries to avoid incorrect historical conversions.
How Make.com and APIs often accept or return IANA names
Many APIs and automation platforms accept IANA names in date/time fields; some return ISO strings with offsets. In Make.com scenarios you’ll see both styles. Prefer exchanging IANA names when you need rule-aware scheduling, and accept offsets if an API only supports them — but convert offsets back to IANA if you need DST behavior.
Mapping user input (city or country) to an IANA zone
Users often say a city or country. Map that to an IANA zone using a city-to-zone lookup or asking clarifying questions when a region has multiple zones. If a user says “New York” map to America/New_York; if they say “Brazil” follow up because Brazil spans zones. Keep a lightweight mapping table for common cities and use follow-ups for edge cases.
Daylight Saving Time (DST) and other anomalies
DST and other local rules are the most frequent source of scheduling problems. Expect ambiguous and missing local times and design your flows to handle them gracefully.
How DST causes ambiguous or missing local times on transitions
During spring forward, clocks skip an hour, so local times in that range are missing. During fall back, an hour repeats, making local times ambiguous. When you ask a user for “2:30 AM” on a transition day, you must detect whether that local time exists or which instance they mean.
Strategies to disambiguate times around DST changes
When times fall in ambiguous or missing ranges, prompt the user: “Do you mean the first 1:30 AM or the second?” or “That time doesn’t exist in your timezone on that date. Do you want the next valid time?” Alternatively, use default policies (e.g., map to the next valid time) but always confirm for critical flows.
Other local rules (permanent shifting zones, historical changes)
Some regions change their rules permanently (abolishing DST or changing offsets). Historical changes may affect past timestamps. Keep tzdb updated and record the IANA zone with event creation time so you can reconcile changes later.
Handling events that cross DST boundaries (scheduling and reminders)
If an event recurs across a DST transition, decide whether it should stay at the same local clock time or shift relative to UTC. Store recurrence rules against an IANA zone and compute each occurrence with tz-aware libraries to ensure reminders fire at the intended local time.
Testing edge cases around DST transitions
Explicitly test for missing and duplicated hours, recurring events that span transitions, and notifications scheduled during transitions. Simulate user travel scenarios and device timezone changes to ensure robustness. Add these cases to your test suite.
Collecting and understanding user time input via voice
Voice has unique constraints — you must design prompts and slots to minimize ambiguity and reduce follow-ups while still capturing necessary data.
Designing voice prompts that capture both date and timezone clearly
Ask for date, time, and timezone explicitly when needed: “What date and local time would you like for your reminder, and in which city or timezone should it fire?” If timezone is likely the same as the user’s device, offer a default and provide an easy override.
Slot design for times, dates, relative times, and modifiers
Use distinct slots for absolute date, absolute time, relative time (“in two hours”), recurrence rules, and modifiers like “morning” or “GMT+2.” This separation helps parsing logic and allows you to validate each piece independently.
Handling vague user input (tomorrow morning, next week) and follow-ups
Translate vague phrases into concrete rules: map “tomorrow morning” to a sensible default like 9 AM local time, but confirm: “Do you mean 9 AM tomorrow?” When ambiguity affects scheduling, prefer short clarifying questions to avoid mis-scheduled events.
Confirmations and read-backs: best phrasing for voice agents
Read back the interpreted schedule in plain language and include timezone: “Okay — I’ll remind you tomorrow at 9 AM local time (Europe/Warsaw). Does that look right?” For cross-zone scheduling say both local and user time: “That’s 3 PM in London, which is 4 PM your time. Confirm?”
Detecting locale from user language vs explicit timezone questions
You can infer locale from the user’s language or device settings, but don’t assume timezone. If precise scheduling matters, ask explicitly. Use language to format prompts naturally, but always validate the timezone choice for scheduling actions.
Fallback strategies when the user cannot provide timezone data
If the user doesn’t know their timezone, infer from device settings, IP geolocation, or recent interactions. If inference fails, use a safe default (UTC) and ask permission to proceed or request a simple city name to map to an IANA zone.
Designing time flows and prototypes in Figma
Prototype your conversational and UI flows in Figma so designers and developers align on behavior, phrasing, and edge cases before coding.
Mapping conversational flows that include timezone questions
In Figma, map each branch: initial prompt, user response, normalization, ambiguity resolution, confirmation, and error handling. Visual flows help you spot missing confirmation steps and reduce runtime surprises.
Creating components for time selection and confirmation in UI-driven voice apps
Design reusable components: date picker, time picker with timezone dropdown, relative-time presets, and confirmation cards. In voice-plus-screen experiences, these components let users visualize the scheduled time and make quick edits.
Annotating prototypes with expected timezone behavior and edge cases
Annotate each UI or dialog with the timezone logic: whether you store IANA name, what happens on DST, and which follow-ups are required. These notes are invaluable for developers and QA.
Using Figma to collaborate with developers on time format expectations
Include expected input and output formats in component specs — ISO strings, example read-backs, and locales. This reduces mismatches between front-end display and backend storage.
Documenting microcopy for voice prompts and error messages related to time
Write clear microcopy for confirmations, DST ambiguity prompts, and error messages. Document fallback phrasing and alternatives so voice UX remains consistent across flows.
Make.com fundamentals for handling time (level 1)
Make.com (automation platform) is often used to wire voice agents to backends and calendars. Learn the basics to implement reliable scheduling and conversions.
Key modules in Make.com for time: Date & Time, HTTP, Webhooks, Schedulers
Familiarize yourself with core Make.com modules: Date & Time for conversions and formatting, HTTP/Webhooks for external APIs, Schedulers for timed triggers, and Teams/Calendar integrations for events. These building blocks let you convert user input into actions.
Converting timestamps and formatting dates using built-in functions
Use built-in functions to parse ISO strings, convert between timezones, and format output. Standardize on ISO 8601 in your flows, and convert to human format only when returning data to voice or UI components.
Basic timezone conversion examples using Make.com utilities
Typical flows: receive user input via webhook, parse into UTC timestamp, convert to IANA zone for local representation, and schedule notifications using scheduler modules. Keep conversions explicit and test with sample IANA zones.
Triggering flows at specific local times vs UTC times
When scheduling, choose whether to trigger based on UTC or local time. For user-facing reminders, schedule by computing the UTC instant for the desired local time and trigger at that instant. For recurring local times, recompute next occurrences in the proper zone each cycle.
Storing timezone info as part of Make.com scenario data
Persist the user’s IANA zone or city in scenario data so subsequent runs know the context. This prevents re-asking and ensures consistent behavior if you later need to recompute reminders.
Make.com advanced patterns for time automation (level 2)
Once you have basic flows, expand to more resilient patterns for recurring events, travel, and calendar integrations.
Chaining modules to detect user timezone, convert, and schedule actions
Build chains that infer timezone from device or IP, validate with user, convert the requested local time to UTC, store both local and UTC values, and schedule the action. This guarantees you have both user-facing context and a reliable trigger time.
Handling recurring events and calendar integration workflows
For recurring events, store RRULEs and compute each occurrence with tz-aware conversions. Integrate with calendar APIs to create events and set reminders; handle token refresh and permission checks as part of the flow.
Rate limits, error retries, and resilience when dealing with external time APIs
External APIs may throttle. Implement retries with exponential backoff, idempotency keys for event creation, and monitoring for failures. Design fallbacks like local computation of next occurrences if an external service is temporarily unavailable.
Using routers and filters to handle zone-specific logic in scenarios
Use routers to branch logic for different zones or special rules (e.g., regions without DST). Filters let you apply transformations or validations only when certain conditions hold, keeping flows clean.
Testing and dry-run strategies for complex time-based automations
Use dry-run modes and test harnesses to simulate time zones, DST transitions, and recurring schedules. Run scenarios with mocked timestamps to validate behavior before you go live.
Scheduling, reminders and recurring events
Scheduling is the user-facing part where mistakes are most visible; design conservatively and validate often.
Design patterns for single vs recurring reminders in voice agents
For single reminders, confirm exact local time and timezone once. For recurring reminders, capture recurrence rules (daily, weekly, custom) and the anchor timezone. Always confirm the schedule in human terms.
Storing recurrence rules (RRULE) and converting them to local schedules
Store RRULE strings with the associated IANA zone. When you compute occurrences, expand the RRULE into concrete datetimes using tz-aware libraries so each occurrence respects DST and zone rules.
Handling user requests to change timezone for a scheduled event
If a user asks to change the timezone for an existing event, clarify whether they want the same local clock time in the new zone or the same absolute instant. Offer both options and implement the chosen mapping reliably.
Ensuring notifications fire at the correct local time after timezone changes
When a user travels or changes their timezone, recompute scheduled reminders against their new zone if they intended local behavior. If they intended UTC-anchored events, leave the absolute instants unchanged. Record the user intent clearly at creation.
Edge cases when users travel across zones or change device settings
Traveling creates mismatch risk between stored zone and current device zone. Offer automatic detection with opt-in, and always surface a confirmation when a change would shift reminder time. Provide easy commands to “keep local time” or “keep absolute time.”
Conclusion
You can build reliable, user-friendly time-aware voice agents by combining clear vocabulary, careful data modeling, thoughtful voice design, and robust automation flows.
Key takeaways for building reliable, user-friendly time-aware voice agents
Use IANA zone names, store UTC timestamps, normalize spoken input, handle DST explicitly, confirm ambiguous times, and test transitions. Treat locale and timezone separately and avoid ambiguous abbreviations.
Recommended immediate next steps: prototype in Figma then implement with Make.com
Start in Figma: map flows, design components, and write microcopy for clarifications. Then implement the flows in Make.com: wire up parsing, conversions, and scheduling modules, and test with edge cases.
Checklist to validate before launch (parsing, conversion, DST, testing)
Before launch: validate input parsing, confirm timezone and locale handling, test DST edge cases, verify recurrence behavior, check notifications across zone changes, and run dry-runs for rate limits and API errors.
Encouragement to iterate: time handling has many edge cases but is solvable with good patterns
Time is messy, but with clear rules — store instants, prefer IANA zones, confirm with users, and automate carefully — you’ll avoid most pitfalls. Iterate based on user feedback and build tests for the weird cases.
Pointers to further learning and resources to deepen timezone expertise
Continue exploring tz-aware libraries, RFC and ISO standards for datetime formats, and platform-specific patterns for scheduling and calendars. Keep your tz database updates current and practice prototyping and testing DST scenarios often.
Happy building — with these patterns you’ll make voice agents that users trust to remind them at the right moment, every time.
If you want to implement Chat and Voice Agents into your business to reduce missed calls, book more appointments, save time, and make more revenue, book a discovery call here: https://brand.eliteaienterprises.com/widget/bookings/elite-ai-30-min-demo-call