在分布式环境中，时区的处理可能非常复杂。例如，您的事件源可能位于一个时区，Collector Manager 位于另一个时区，后端 Sentinel 服务器位于第三个时区，而查看数据的客户端位于第四个时区。当您添加夏令时间和许多没有报告为它们所设置的时区的时间源（如所有 syslog 源）等问题时，需要处理许多可能出现的问题。Sentinel 非常灵活，您可以正确表示事件实际发生的时间，将这些事件与来自相同或不同时区内的其他源的其他事件进行比较。
一般而言，在处理事件源报告时间戳的方式上，有 3 种方案：
事件源以 UTC 的形式报告时间。例如，所有标准的 Windows 事件日志总是以 UTC 形式进行报告。
事件源报告本地时间，但始终在时间戳中包含该时区。例如，构造时间戳过程中遵循 RFC3339 日期格式的任何事件源都包含时区，用它作为偏移，其他事件源会报告长时区 ID（如美国/纽约）或短时区 ID（如 EST），由于存在冲突的和不充分的解决方法，所以可能导致一些问题。
事件源报告本地时间，但不指明时区。不幸的是，极其常见的 syslog 格式也采用此模式。
对于第一种方案，您可以始终计算发生事件的绝对 UTC 时间（假设使用了一种时间同步协议），所以您可以轻松地对比该事件发生的时间和世界其他事件源的时间。但是，您无法自动确定发生时间的本地时间是何时。出于此原因，Sentinel 允许客户手动设置事件源的时区，方法是编辑事件源管理器中的事件源节点并指定合适的时区。此信息不会影响 DeviceEventTime 或 EventTime 的计算，但它位于 ObserverTZ 字段中，可用于计算各种 ObserverTZ 字段，如 ObserverTZHour。这些字段始终使用本地时间表示。
在第二种方案中，如果使用长格式时区 ID 或偏移量，则可通过转换为 UTC 来获得绝对权威的 UTC 时间（储存在 DeviceEventTime 中），但您也可以计算本地时间 ObserverTZ 字段。如果使用短时区 ID，可能会发生冲突。
第三种方案需要管理员来手动设置所有受影响源的事件源时区，以便 Sentinel 可以正确计算 UTC 时间。如果通过在事件源管理器中编辑事件源节点来正确指定了时区，那么 DeviceEventTime（以及可能 EventTime）可能不正确，ObserverTZ 和相关联的字段可能也不正确。
一般而言，给定类型的事件源（如 Microsoft Windows）的收集器知道事件源如何提供时间戳，并相应地进行调整。在事件源管理器中为所有事件源节点手动设置时区始终是一种不错的策略，除非知道事件源报告本地时间并始终在时间戳中包含时区
对事件源的时间戳表示形式的处理是在收集器中和 Collector Manager 上进行的。DeviceEventTime 和 EventTime 储存为 UTC，ObserverTZ 字段储存为设置为事件源本地时间的字符串。此信息从 Collector Manager 发送到 Sentinel 服务器并储存在事件储存中。Collector Manager 和 Sentinel 服务器所在的时区不应影响此进程或储存的数据。但是，当客户端在 Web 浏览器中查看事件时，UTC EventTime 会根据 Web 浏览器转换为本地时间，因此所有事件都是按本地时区显示给客户端的。如果用户希望查看源的本地时间，他们可以检查 ObserverTZ 字段以了解详细信息。