TZDATETIME
Builds a zone-aware instant from a wall-clock time in a zone
Try it
When to use it
When should I use TZDATETIME instead of TZPARSE or TZLOCALIZE?
Use TZDATETIME when you already have discrete year, month, day, hour, minute, and second values — such as numbers from separate cells or calculations — and want to assemble them into a zone-aware instant. TZPARSE is better when you have a date-time string to decode, and TZLOCALIZE is better when you have an existing naive timestamp to attach a zone to.
What happens when my local wall-clock time falls in a DST gap or fold?
By default the policy is reject, which returns #VALUE! to alert you that the time is ambiguous or non-existent. You can pass earliest or latest to resolve a fold (two local times map to one clock reading), or compatible to silently pick a reasonable value, depending on how your use case should handle the ambiguity.
Is the result of TZDATETIME a display string or a real point in time?
It is a Zoned instant — a pinned moment in time with a specific offset — not just a formatted string. You can pass it directly to TZCONVERT to shift zones, compare it to other zoned values, or extract components from it.
Use cases
Build a New York business-hours deadline with DST awareness
Create a Tokyo shift start for payroll calculation
Used in
operations · hr · engineering
Syntax
TZDATETIME(year,month,day,hour,minute,second,zone,[policy])