Two clock readings on different dates can describe the same event. When importing logs, changing the offset should preserve that instant unless the task is explicitly to correct an incorrectly recorded time. Keep those two operations separate.

DateTimeZone.SwitchZone takes a datetimezone value and a new offset in hours, with optional minutes. Microsoft documents an error when the input has no timezone component. Use a typed zoned value; do not remove its offset first and then assume the remaining clock reading still identifies the same instant.

Make the date boundary visible

In a separate Power Query practice expression, use this fictional timestamp: 1 January 2026 at 00:30 with an explicit offset of +13:00. Convert it to offset zero:

DateTimeZone.SwitchZone(#datetimezone(2026, 1, 1, 0, 30, 0, 13, 0), 0)

The expected result is 31 December 2025 at 11:30 with offset +00:00. Subtracting thirteen hours crosses both midnight and the year boundary. Compare the full year, month, day, hour and offset rather than accepting a time-of-day match alone.

Convert that result back to +13:00 and compare it with the original zoned timestamp. The round trip should restore 1 January at 00:30. A result that keeps the original clock reading while merely relabelling its offset would describe a different instant.

Keep missing zone information unresolved

Try the separate unzoned value #datetime(2026, 1, 1, 0, 30, 0) as the input to SwitchZone and observe the documented error. Do not silently supply whichever zone your current computer uses. Obtain the source system's timestamp convention before deciding how an unzoned value should be interpreted.

The function's arguments specify numeric offsets, not a named region or its daylight-saving rule history. The +13:00 example is an explicit fixture, not a claim that a particular city always uses that offset. If the source requires regional rules, resolve the correct offset for each relevant date through an appropriate documented process.

Retain the original timestamp and its convention with the converted output. Acceptance means the two representations identify the same instant, including across a date boundary, and missing zone information has not been disguised as a successful conversion.

Sources: Microsoft: DateTimeZone.SwitchZone.