A cloud flow receives a Dataverse createdon value in UTC and must write it into an email as local time for a team in the Eastern Standard Time zone, formatted as yyyy-MM-dd HH:mm. The result must stay correct when daylight saving time begins or ends. Which expression should the developer use?
Select an answer to reveal the explanation.
Short Explanation
Subtracting five hours works right up until the clocks change, then you're an hour off for half the year. convertTimeZone knows the zone's daylight saving rules and formats the result in one go. Watch the direction too; convertToUtc goes the wrong way.
Full Explanation
convertTimeZone takes a timestamp, a source time zone, a destination time zone, and an optional format string. Given the UTC createdon value, a source of UTC, and a destination of Eastern Standard Time, it applies the zone's rules, including daylight saving transitions, and returns the formatted local time. Windows time zone names are used, and the Eastern Standard Time identifier covers both standard and daylight periods. Adding a fixed negative five hours ignores daylight saving entirely, so the email shows the wrong hour for the part of the year when the offset is four hours. convertToUtc converts from a named source zone into UTC; applying it to a value that is already UTC shifts the time in the wrong direction and produces a meaningless result. formatDateTime formats a timestamp and accepts an optional locale as its third argument, such as a culture name; it does not accept a time zone, so it cannot convert the value to local time. Exam caveat: Dataverse returns date and time columns with User Local behavior as UTC through the API, so conversion in the flow is required even when the app shows local time. Operational check: test with one timestamp in January and one in July and confirm the outputs differ in offset by one hour.