Haiku Time Settings: Time Zones, RTC Mode, and NTP Sync

Haiku time configuration contains several values that are easy to confuse: the current system clock, the selected time zone, the hardware real-time clock (RTC) convention, and optional network-time synchronization. A clock that appears wrong can result from any one of these layers. Changing the time zone does not necessarily fix the hardware clock, and selecting GMT for the RTC does not select the user’s display time zone.

The official Time preferences panel exposes these settings. Its current User Guide lists separate configuration files for network-time settings, the hardware-clock mode, and the time-zone choice. Use the supported panel and its synchronization action rather than editing those files by hand. Their names and formats are implementation details that can change.

Distinguish wall-clock time from time-zone presentation

The system clock represents the current time; the time zone determines how local date/time is presented. Locale preferences separately affect formatting conventions such as date order, number punctuation, and month/day names. A correct clock displayed in the wrong zone may be off by a fixed number of hours while remaining internally synchronized. A wrong locale can change the written form without changing the instant represented.

When comparing a Haiku clock to a phone, server, or dual-boot operating system, record the time zone and whether each device is showing local time or UTC/GMT. Compare the same instant, not just the hour displayed. If a file timestamp looks different in another OS, inspect timezone and filesystem timestamp interpretation before changing the clock.

Open Deskbar → Preferences → Time. The Date and Time tab sets calendar and clock values. The Time Zone tab lets the user select a region and preview the selected zone’s time. Make a note of the old zone before changing it, especially on a machine with scripts or scheduled jobs that interpret local time.

Choose the hardware RTC convention deliberately

The panel’s RTC setting controls whether the hardware clock is interpreted as local time or GMT. The Haiku User Guide notes that local time is normally useful when dual-booting into Windows, while GMT is the Unix-compatible convention. This is a cross-OS coordination choice: if the other system assumes a different convention, each boot can appear to shift the clock.

Do not toggle between local and GMT repeatedly to “see what sticks.” Record the current mode, time zone, and behavior after a full shutdown and cold boot. A setting that looks right in the currently running OS can still be wrong after another OS writes the RTC. Choose one intended convention for the machine’s boot configuration and make the other operating system consistent where possible.

If time resets after power loss, distinguish a dead/weak RTC battery from an OS configuration error. If time changes only after booting another OS, investigate the RTC convention and that OS’s settings. If it drifts while Haiku remains running, investigate synchronization and clock behavior rather than reinstalling the time-zone database.

Configure NTP through the panel

The Network Time tab lets users add or remove NTP servers, choose whether Haiku tries all servers during synchronization, and enable synchronization at boot. It also offers a reset to the default server list and a manual synchronization action. Network time requires working network connectivity and a reachable server; it cannot correct a disconnected interface or failed DNS path.

Use a small, known-good server list and do not add random public hosts from an unverified forum post. If synchronization fails, confirm the network interface, route, DNS, and system date are plausible. A badly incorrect clock can also complicate certificates and logs, so record the current value before attempting an update.

The user guide documents this command-line form for manual synchronization:

Time --update

This is a state-changing synchronization action, not a dry run. Run it only when the system should adopt the network time and preserve the command output/error for diagnosis. The panel’s Synchronize action is also available. Neither action proves that time-zone selection or the hardware RTC convention is correct.

Troubleshoot a time that keeps moving

First record time, time zone, RTC mode, whether a sync is configured at boot, and whether the computer dual-boots. Check the network separately. If NTP cannot reach a host, the problem may be name resolution, route, firewall, or server availability. Compare the time before and after one manual sync and note whether the offset is stable or growing.

If the displayed time changes by a constant whole-hour offset after reboot, inspect the time zone and RTC mode. If the offset changes after booting another OS, compare RTC conventions across installations. If the clock loses time while powered off, inspect hardware/firmware and RTC battery. If it slowly drifts while running and NTP is disabled, enable a documented synchronization policy rather than repeatedly setting it by hand.

When log timestamps disagree, do not rewrite logs or change clock values to make an incident timeline look tidy. Preserve the original timestamps and note the offset, time zone, and synchronization event. For a bug report, include the Haiku revision, hardware, dual-boot state, RTC mode, server/sync policy without credentials, and before/after readings.

Keep Locale formatting separate

Haiku’s Locale Kit formats dates and times according to the user’s preferences. That is distinct from selecting the time zone and from setting the system clock. If the month/day order or localized names look wrong while the instant is correct, inspect Locale formatting. If the hour is offset, inspect the zone/RTC layers. This separation prevents a formatting change from being used to mask a clock error.

Applications should use supported date/time APIs and locale-aware formatting rather than parsing the visible string from the Deskbar clock. Persisting a local timestamp without its time zone can make later interpretation ambiguous, especially across daylight-saving transitions. When recording events for a protocol or forensic report, use an explicit offset or UTC representation when the API and format support it.

Acceptance checklist

Verify the correct zone and displayed local time, choose the intended RTC convention, test a manual NTP sync, and reboot once to confirm persistence. If the machine dual-boots, test both operating systems and confirm the clock does not jump. Test network loss and recovery if automatic synchronization is enabled. Check a file timestamp and an application log against a known reference.

Use a diagnostic matrix rather than repeatedly changing settings. Capture readings at four checkpoints: before synchronization, immediately after the manual update, after a warm reboot, and after booting the other operating system. At each checkpoint record the displayed local time, selected zone, RTC mode, and whether the network is available. A constant offset after every checkpoint points toward zone interpretation; a jump only after a second OS writes the RTC points toward mismatched RTC conventions; gradual drift while powered on is a different symptom from time loss while powered off. This evidence makes a repair testable and reversible.

Be careful when comparing scheduled jobs around daylight-saving transitions. A local wall-clock time can be skipped or repeated when rules change, whereas a timestamp with an explicit UTC offset identifies a specific instant more clearly. Do not infer that a locale-formatting change corrected the underlying clock or zone. For services that persist event times, store or emit an unambiguous representation where the API permits it, and render local time only at the user-facing boundary.

When a network update changes the clock unexpectedly, preserve the before-and-after readings and synchronization output before attempting another correction. Confirm that the configured server name resolves and that the machine has a working route; the Time preferences server list does not guarantee the network path is available. If automatic synchronization is enabled at boot, test its behavior with the network disconnected and then restored, and note whether the system corrects itself later. Avoid claiming that one successful manual sync proves the boot-time policy, RTC mode, or time-zone selection is correct.

For a support report, redact no timestamps needed to establish the offset, but remove network credentials and private server names when they are sensitive. Include the local zone name rather than only an abbreviation, because abbreviations can be ambiguous. State whether the hardware clock is configured as GMT or local time and identify every operating system that writes it. This makes dual-boot clock reports actionable without asking the next person to reproduce an undocumented sequence.

The success criterion is not simply that the Deskbar clock looks plausible once. It is that the system clock, zone, RTC convention, and synchronization behavior remain consistent across reboots and other operating systems. Keeping those layers separate makes clock drift diagnosable without hiding the underlying cause.

Related:

Sources: