Best practice in APROL 4.4 P00 that allows alarm history timestamps?

What’s happening

In APROL 4.4 P00, alarm events displayed in the Web Alarm History are logged using the local time at the moment the alarm occurs.

When the system time zone is later changed, previously logged alarm entries retain their original timestamps and are not adjusted to the new time zone. Only newly generated alarms are logged according to the updated time zone setting.

This behavior can cause the alarm sequence in the history view to appear incorrect, especially on vessels that frequently travel across different time zones. As shown in the attached screenshot, Alarm #1 actually occurred before Alarm #2, but after the time zone change, Alarm #2 is displayed with an earlier timestamp, resulting in an incorrect chronological order in the alarm history.

We would like to know if there is a way to:

  • Automatically convert historical alarm timestamps when the system time zone changes, or
  • Store and display alarm timestamps in UTC regardless of the local time zone setting.

What you’ve tested

  • Generated alarms while the system was operating in one time zone.
  • Changed the system time zone to a different region.
  • Generated additional alarms after the time zone change.
  • Verified the Alarm History in the Web Visualization.

Results:

  • Historical alarm records kept their original local timestamps.
  • Newly generated alarms were logged according to the new time zone.
  • Alarm timestamps from different time zones were mixed together in the same history view, causing the displayed event sequence to become misleading.

Your software/hardware type and version

Software

  • APROL 4.4 P00
  • Web Alarm History / Web Visualization

Hardware

  • B&R APROL System installed on a marine vessel application
  • (Please add controller/server hardware details if required)

Question

Is there any supported configuration, setting, or best practice in APROL 4.4 P00 that allows alarm history timestamps to:

  1. Follow the currently selected time zone dynamically, including historical records, or
  2. Be stored and displayed exclusively in UTC to maintain the correct chronological order of alarm events when moving between different time zones?

Attached screenshot illustrates the issue where the actual event sequence differs from the displayed order after a time zone change.

I hope @tomas.miculka or @christian.peham can help here :slight_smile: