Applies to: A clock selector or handwritten note rounds a time difference to whole hours.
The useful distinctions
- Some current timezone offsets include a half hour.
- Rounding the offset changes the resulting instant.
- A date-aware location conversion is more informative than a rounded manual difference.
Retain the minutes in the comparison
A conversion can look plausible at the hour level while still placing a programme thirty minutes away from its intended slot. Preserve the minute component from the date-aware result rather than rounding it to a whole-hour setting. If the available interface cannot represent the required value, record that limitation and ask about a supported approach. Do not compensate by inventing a different start time for the programme itself.
Use a dated example to narrow the issue
Choose one source timestamp whose context is clear and compare the complete local result. If the displayed guide differs by thirty minutes, keep that observation separate from a wrong channel identity or a programme overrun. A half-hour discrepancy is evidence to investigate, not proof of one universal setting error. Keep the original timestamp available so the source owner can determine which stage of the comparison lost the minutes.
Hypothetical worked example
For the documented 18:00 UTC instant on 8 November 2026, Asia/Tehran reads 21:30. A fictional note rounded to “three hours ahead” would instead place it at 21:00. That thirty-minute gap is introduced by the rounding, not by any established change to the event. The viewer reports the full 21:30 result and the rounded display rather than applying another whole hour to every programme in the guide.
A focused way to proceed
- Keep the original source timestamp.
- Use a location-aware conversion that preserves minutes.
- Compare a known programme boundary before changing any whole-hour guide setting.
When to stop or ask for help
Preserve the half-hour component and ask for a supported date-aware comparison if the interface cannot represent it.