{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/choose-one-axis-time-zone-source-and-verify-the-active-result/", "item": { "id": "https://update.dsesecurity.com/updates/choose-one-axis-time-zone-source-and-verify-the-active-result/", "slug": "choose-one-axis-time-zone-source-and-verify-the-active-result", "url": "https://update.dsesecurity.com/updates/choose-one-axis-time-zone-source-and-verify-the-active-result/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/choose-one-axis-time-zone-source-and-verify-the-active-result.md", "json": "https://update.dsesecurity.com/api/v1/posts/choose-one-axis-time-zone-source-and-verify-the-active-result/" }, "title": "Choose one Axis time zone source and verify the active result", "summary": "Axis Time API makes IANA, POSIX and DHCP time-zone sources mutually exclusive. Choose the intended source and verify the active zone rather than assuming every stored field is in use.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "managed-it", "label": "Managed IT operations", "alt": "A controlled technology lifecycle progressing from assessment to approved production.", "card_url": "https://update.dsesecurity.com/assets/editorial/managed-it-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/managed-it-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-29T00:10:19+00:00", "modified_at": "2026-10-29T00:10:34+00:00", "reviewed_on": "2026-10-28", "reading_minutes": 3, "word_count": 514, "potentially_affected": "Axis devices exposing the documented Time API interface; confirm support and the installed API/software scope before applying the proposed checks.", "dse_recommendation": "DSE recommends recording one intended time-zone source per device configuration and verifying its active value.", "primary_source": { "name": "Axis Communications — Time API", "url": "https://developer.axis.com/vapix/device-configuration/time-api/", "published_on": null, "authority": "Axis Communications" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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

\n

Source fact: documented behavior

\n

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

\n

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

\n

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.

\n

What the source does not establish

\n

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.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

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

\n

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

\n
    \n
  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. \n
  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. \n
  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.
    4. \n
\n

Verification and evidence

\n

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.

\n

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.

\n

Official references

\n\n

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

\n", "content_text": "Bottom line: Choose the source of the device’s time-zone rules explicitly, then inspect the active result after applying the supported configuration.\nSource fact: documented behavior\nThe Time API documentation says IANA, POSIX and DHCP time-zone settings are mutually exclusive.\nIt identifies the active-time-zone property as the way to check which zone the device currently uses.\nFor an IANA zone, the topic says the selected zone’s daylight-saving rules are applied and database updates are included through AXIS OS upgrades.\nWhat the source does not establish\nDo 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.\nApplicability questions\n\nShould the device use an explicitly selected IANA zone, a POSIX definition or a DHCP-provided zone?\nWho controls the chosen source and any later change to it?\nWhat active-zone value should the supported readback show?\nWhich operator and recording workflows need a time-display comparison during the proposed check?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends recording one intended time-zone source per device configuration and verifying its active value.\n\nAsk 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.\nUse 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.\nFor 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.\n\nVerification and evidence\nRetain 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.\nRepeat 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.\nOfficial references\n\nTime API — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "content_markdown": "Bottom line: Choose the source of the device’s time-zone rules explicitly, then inspect the active result after applying the supported configuration.\n\n## Source fact: documented behavior\n\nThe [Time API](https://developer.axis.com/vapix/device-configuration/time-api/) documentation says IANA, POSIX and DHCP time-zone settings are mutually exclusive.\n\nIt identifies the active-time-zone property as the way to check which zone the device currently uses.\n\nFor an IANA zone, the topic says the selected zone’s daylight-saving rules are applied and database updates are included through AXIS OS upgrades.\n\n## What the source does not establish\n\nDo 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.\n\n## Applicability questions\n\n- Should the device use an explicitly selected IANA zone, a POSIX definition or a DHCP-provided zone?\n\n- Who controls the chosen source and any later change to it?\n\n- What active-zone value should the supported readback show?\n\n- Which operator and recording workflows need a time-display comparison during the proposed check?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends recording one intended time-zone source per device configuration and verifying its active value.\n\n- 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.\n\n- 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.\n\n- 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.\n\n## Verification and evidence\n\nRetain 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.\n\nRepeat 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.\n\n## Official references\n\n- [Time API](https://developer.axis.com/vapix/device-configuration/time-api/) — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/choose-one-axis-time-zone-source-and-verify-the-active-result/", "url": "https://update.dsesecurity.com/updates/choose-one-axis-time-zone-source-and-verify-the-active-result/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/choose-one-axis-time-zone-source-and-verify-the-active-result/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Networks & Infrastructure", "item": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "ListItem", "position": 3, "name": "Choose one Axis time zone source and verify the active result", "item": "https://update.dsesecurity.com/updates/choose-one-axis-time-zone-source-and-verify-the-active-result/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/choose-one-axis-time-zone-source-and-verify-the-active-result/#article", "identifier": "https://update.dsesecurity.com/updates/choose-one-axis-time-zone-source-and-verify-the-active-result/", "url": "https://update.dsesecurity.com/updates/choose-one-axis-time-zone-source-and-verify-the-active-result/", "headline": "Choose one Axis time zone source and verify the active result", "description": "Axis Time API makes IANA, POSIX and DHCP time-zone sources mutually exclusive.", "abstract": "Axis Time API makes IANA, POSIX and DHCP time-zone sources mutually exclusive. Choose the intended source and verify the active zone rather than assuming every stored field is in use.", "articleBody": "Bottom line: Choose the source of the device’s time-zone rules explicitly, then inspect the active result after applying the supported configuration.\nSource fact: documented behavior\nThe Time API documentation says IANA, POSIX and DHCP time-zone settings are mutually exclusive.\nIt identifies the active-time-zone property as the way to check which zone the device currently uses.\nFor an IANA zone, the topic says the selected zone’s daylight-saving rules are applied and database updates are included through AXIS OS upgrades.\nWhat the source does not establish\nDo 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.\nApplicability questions\n\nShould the device use an explicitly selected IANA zone, a POSIX definition or a DHCP-provided zone?\nWho controls the chosen source and any later change to it?\nWhat active-zone value should the supported readback show?\nWhich operator and recording workflows need a time-display comparison during the proposed check?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends recording one intended time-zone source per device configuration and verifying its active value.\n\nAsk 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.\nUse 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.\nFor 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.\n\nVerification and evidence\nRetain 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.\nRepeat 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.\nOfficial references\n\nTime API — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "datePublished": "2026-10-29T00:10:19+00:00", "dateModified": "2026-10-29T00:10:34+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/choose-one-axis-time-zone-source-and-verify-the-active-result/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/choose-one-axis-time-zone-source-and-verify-the-active-result/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Choose one Axis time zone source and verify the active result" }, "articleSection": [ "Networks & Infrastructure", "Video Surveillance" ], "keywords": [ "Networks & Infrastructure", "Video Surveillance", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "Thing", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "wordCount": 514, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Axis Communications — Time API", "url": "https://developer.axis.com/vapix/device-configuration/time-api/" } } ] } }