Pipeline expression function convertTimeZone() should support IANA/Windows time zones with DST

[AdamCoulterOz]

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