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 ... View more