在分散式環境中處理時區是相當複雜的工作。例如，您的事件來源可能位在某個時區中，收集器管理員位在另一個時區中，後端的 Sentinel 伺服器又位在另一個時區中，而檢視資料的用戶端則位在其他時區中。當您加入如日光節約時間等考量及許多不報告所在時區的事件來源 (如所有 Syslog 來源) 時，便需要處理許多可能的問題。Sentinel 的彈性能讓您在事件發生時適當地呈現時間，也能讓您將事件與來自其他位在相同或相異時區之來源的事件做比較。
一般來說，事件來源報告時間戳記的方式可分為三種情境：
事件來源報告 UTC 時間。例如，所有標準的 Windows 事件記錄檔事件一律報告 UTC 時間。
事件來源報告本地時間，但一律會在時間戳記中加上時區。例如，任何遵循使時間戳記結構化之 RFC3339 的事件來源均會加入時區以做為偏移；其他來源則會報告詳細的時區 ID (如 Americas/New York) 或簡短的時區 ID (如 EST)，由於衝突和解析不當等因素，這可能會造成問題。
事件來源報告本地時間，但未加入時區。很遺憾，最普遍的 Syslog 格式遵循此模式。
對於第一種情境，您一律可以計算事件發生時的絕對 UTC 時間 (假設時間同步化通訊協定正在使用中)，因此可以輕易地將事件時間與世界中的其他事件來源做比較。不過您不能自動判斷事件發生時的本地時間。有鑑於此，Sentinel 允許客戶在事件來源管理員中編輯事件來源節點，以利用手動的方式設定事件來源的時區，以及指定適當的時區。這項資訊不會影響「設備事件時間」或「事件時間」的計算，但系統會將其放置在「觀察者時區」欄位中，並且用來計算各個「觀察者時區」欄位 (如「觀察者時區小時」)。這些欄位一律以本地時間來表示。
對於第二種情境，如果系統使用詳細時區 ID 或偏移，您除了可以轉換為 UTC 以取得絕對規範化 UTC 時間 (儲存在「設備事件時間」中) 之外，還能計算本地時間「觀察者時區」欄位。但如果使用簡短時區 ID，可能會造成某些衝突。
第三種情境需要所有受影響來源的管理員手動設定事件來源時區，Sentinel 才能正確計算 UTC 時間。如果您未藉由編輯事件來源管理員的事件來源節點來指定正確的時區，「設備事件時間」(或甚至「事件時間」) 可能會是錯誤的。此外，「觀察者時區」和相關的欄位也可能會是錯誤的。
一般來說，指定類型之事件來源 (如 Microsoft Windows) 的收集器都知道事件來源呈現時間戳記的方式，因此都能隨著調整。除非您知道事件來源報告是以本地時間為準且一律在時間戳記中加上時區，否則在事件來源管理員中針對所有事件來源節點手動設定時區會是放諸四海皆準的規則。
收集器和收集器管理員是負責處理時間戳記之事件來源呈現的裝置。「設備事件時間」和「事件時間」是以 UTC 的格式儲存，而事件來源的「觀察者時區」欄位則是以設定為本地時間的字串格式儲存。這項資訊會從收集器管理員傳送至 Sentinel 伺服器，且儲存在事件儲存中。收集器管理員和 Sentinel 伺服器所在的時區不會影響這個程序或儲存的資料。然而當用戶端在網頁瀏覽器中檢視事件時，由於系統會依據網頁瀏覽器將 UTC 事件時間轉換為本地時間，因此在將所有事件呈現給用戶端時是以本地時區為準。如果使用者想要查看來源的本地時間，他們能查驗「觀察者時區」欄位以取得詳細資料。