Timezones are where a lot of automation quietly goes wrong. A workflow that looks correct in testing sends a reminder an hour early, logs a meeting on the wrong day, or writes a timestamp that is off just enough that nobody notices until a client does. n8n bundles Luxon, a capable date and time library, which makes handling this correctly straightforward once you understand the few rules that matter.
Why timezone bugs are so easy to create
The root problem is ambiguity. A timestamp like “2 p.m.” means nothing without a timezone, and systems disagree about what they assume when one is missing. An API might return times in UTC, your CRM might display them in the account’s timezone, and your workflow might run on a server set to a third. Every place these assumptions differ is a place an hour can appear or vanish.
The fix is discipline: know the timezone of every timestamp you handle, convert deliberately, and never let a “naive” time with no timezone flow through your logic.
Store in UTC, display in local
The pattern that prevents most of these bugs is simple. Store and compute in UTC, and convert to a local timezone only when you present the time to a human or write it to a system that expects local time. UTC has no daylight saving shifts and no ambiguity, which makes it the safe common ground for all your internal logic.
Luxon makes this clean. You parse an incoming time while specifying its zone, convert to UTC for storage and comparison, and convert to the target zone at the moment of display. The key is always being explicit about which zone a time is in at each step, rather than hoping the default is right.
Watch out for daylight saving
Daylight saving is where naive date math breaks. Adding “one day” to a timestamp across a daylight saving boundary is not always adding exactly twenty-four hours, and treating it as if it is produces off-by-one-hour errors twice a year. Luxon handles this correctly when you work in a real timezone rather than raw offsets, which is another reason to convert deliberately instead of doing arithmetic on raw numbers.
Format for the destination, not for yourself
Different systems want timestamps in different shapes. Some want ISO 8601, some want Unix epoch seconds, some want a specific human-readable format. Decide what the receiving system expects and format for it explicitly at the boundary. A mismatched format is a common, avoidable cause of “the integration rejected my data” errors that have nothing to do with your actual logic.
The rule that prevents most problems
If you take one thing away: never let a timestamp move through your workflow without knowing its timezone. Parse with an explicit zone, compute in UTC, convert at the edges. That single habit eliminates the large majority of timezone bugs before they happen.
Growth Wizard builds automation that gets these details right, because an hour off is the kind of small error that erodes trust in an entire system. If your workflows have a habit of drifting off by an hour, this is usually why.
