Choose one Axis time zone source and verify the active result

Bottom line: Choose the source of the device’s time-zone rules explicitly, then inspect the active result after applying the supported configuration.

Source fact: documented behavior

The Time API documentation says IANA, POSIX and DHCP time-zone settings are mutually exclusive.

It identifies the active-time-zone property as the way to check which zone the device currently uses.

For an IANA zone, the topic says the selected zone’s daylight-saving rules are applied and database updates are included through AXIS OS upgrades.

What the source does not establish

Do not use this time-zone decision as a substitute for checking clock synchronization or the timestamp requirements of the recording workflow. Confirm which documented API and settings the installed product supports. Avoid assuming that a familiar local display proves every receiving system interprets timestamps identically. Keep any legacy-interface migration as separately reviewed work rather than extending this article into a version forecast.

Applicability questions

• Should the device use an explicitly selected IANA zone, a POSIX definition or a DHCP-provided zone?
• Who controls the chosen source and any later change to it?
• What active-zone value should the supported readback show?
• Which operator and recording workflows need a time-display comparison during the proposed check?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends recording one intended time-zone source per device configuration and verifying its active value.

1. Ask the system owner to select the intended source and write its expected zone definition on the change record. Coordinate a DHCP-based proposal with the network owner instead of treating it as a device-only preference. Keep the selected policy distinct from clock-source configuration and from the way a separate client chooses to display time.
2. Use the supported API on a representative noncritical device to read the current zone settings and active result. Apply the approved source selection through the documented procedure, then read the active result again. Compare the result with the written expectation before changing additional devices. Do not interpret unused or cleared alternative fields as a second simultaneously active policy.
3. For a proposed acceptance exercise, compare the device’s reported time context with an agreed event marker and the intended operator workflow. Where seasonal rules matter, have the responsible specialist review the chosen zone and the supported way to test the relevant transition. Avoid changing a production clock merely to manufacture a convenient demonstration.

Verification and evidence

Retain the selected-source decision, exact zone definition, device/software identity, before-and-after settings and active-zone readback. Record the agreed event marker and which client or recording view was compared. Keep any synchronization investigation separate so a time-display question is not closed with unrelated evidence.

Repeat the proposed review after a network time-zone policy change, a device replacement or a relevant software change. Preserve disagreements between the device and receiving systems for investigation. These are proposed DSE checks; this article claims no observed clock accuracy, seasonal transition or end-to-end timestamp agreement.

Official references

• Time API — Axis Communications; official VAPIX documentation.

Source review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.