Compare Lord Howe with Sydney across the season
The same UTC hour is converted below before and after the seasonal change. The table preserves minutes, so the change in the relationship is visible rather than rounded away.
| UTC example | Australia/Lord_Howe | Australia/Sydney |
|---|---|---|
| 2026-09-20 10:00:00 UTC | 2026-09-20 20:30 (UTC+10:30) | 2026-09-20 20:00 (UTC+10:00) |
| 2026-11-03 10:00:00 UTC | 2026-11-03 21:00 (UTC+11:00) | 2026-11-03 21:00 (UTC+11:00) |
| 2027-07-15 10:00:00 UTC | 2027-07-15 20:30 (UTC+10:30) | 2027-07-15 20:00 (UTC+10:00) |
Diagnose the guide separately from the device
If the device already has the right local clock, moving that clock to repair one programme list can affect unrelated apps and reminders. Compare the source programme time with the guide’s displayed result first. A persistent 30-minute difference is a different clue from a one-hour seasonal error.
Where the player accepts named zones, use the actual location. Where it accepts only a fixed guide shift, understand that the correction is limited to that guide and may need review for another season. It does not become a permanent description of the island’s time.
Keep the date in any saved reminder
A recurring reminder should retain the event’s source zone and date. A future civil-time change can alter its conversion even if the programme continues at the same source-local hour. Recheck the broadcaster’s schedule close to the event; these calculations do not predict a programme’s own schedule change.
Questions about this guide
Is Lord Howe always the same clock as Sydney?
No. The dated examples show their seasonal relationship. Use Australia/Lord_Howe rather than a substitute city.
Will a one-hour EPG adjustment fix a 30-minute error?
Not accurately. Use the actual location setting or a guide control that can represent the required minutes.