Status:
New
Pipeline expression function convertTimeZone() should support IANA/Windows time zones with DST
Problem:
The built-in convertTimeZone() expression in Fabric Pipelines only supports fixed-offset “Standard Time” IDs like "AUS Eastern Standard Time" — which do not handle daylight saving time.
@convertTimeZone(utcNow(), 'UTC', 'AUS Eastern Standard Time')
This always returns UTC+10, even when the actual timezone (e.g. Australia/Sydney) is UTC+11 due to DST.
⸻
😫 Why this matters
Time-based partitioning is core to nearly every pipeline use case. If I want to:
• Schedule daily jobs
• Partition by calendar day
• Roll tumbling windows
• Use startOfDay() or addDays() reliably…
…I need an accurate, DST-aware timezone conversion. Today, we’re forced to do this:
• Use notebooks or scripts to calculate the real local midnight
• Patch offsets manually (+10 or +11 depending on date)
• Maintain workarounds just to replace what the platform should provide
⸻
✅ What we expected
@convertTimeZone(utcNow(), 'UTC', 'Australia/Sydney')
Would:
• Use the correct offset (UTC+10 or +11 depending on date)
• Respect DST transitions
• Align with how every real programming language does timezone handling
⸻
💥 What we got
A misleading “timezone” function that returns broken results half the year and forces every user to reimplement what the platform already has internally.
⸻
📢 Request
Please support true time zone conversion using:
• Windows time zone IDs with DST (e.g. AUS Eastern Standard Time as implemented in TimeZoneInfo)
• or IANA time zones (e.g. Australia/Sydney)
And align with how TimeZoneInfo.ConvertTimeBySystemTimeZoneId(...) behaves in .NET.
⸻
🧠 Bonus points
• Let users call now() in a specific timezone (now('Australia/Sydney'))
• Let startOfDay()/endOfDay() operate in that timezone natively
• Add a currentTimeZone() function to inspect system behaviour
No CommentsBe the first to comment
