Inconsistent between_start and between_end values in REST API for C_PERIOD executions during DST transitions.

Products

• CA Automic Workload Automation - Automation Engine
• Automic Automation

Issue/Introduction

When querying recurring execution objects (C_PERIOD) via the Automic REST API, the values for between_start and between_end may appear inconsistent when the execution period spans across a Daylight Saving Time (DST) change (e.g., from Winter/CET to Summer/CEST). This behavior is often reported when the returned UTC values shift by one hour despite the local execution window remaining the same in the Automic Web Interface (AWI).

Symptoms:

• The REST API returns different UTC values for the execution window than what is stored in the database.
• The between_end value shifts by a calendar day or hour when crossing midnight or DST boundaries.
• Reports generated via REST API show inconsistent trigger times for the same recurring task.

Environment

• Automic Automation Engine 26.X, 24.x
• Timezone objects with DST enabled (e.g., TZ.CET, TZ.CEST)
• Recurring execution (C_PERIOD) tasks

Cause

This behavior is by design. The between_start and between_end fields define the daily allowed execution window. These values are timezone-aware. When retrieved via the REST API, the system converts the local time (e.g., 08:00 CET) to UTC.

For C_PERIOD objects without a fixed end date, the system recalculates the daily window every day based on the current execution date (EPD_RANGEEND). Consequently, the UTC conversion factor changes depending on whether that specific date falls within a DST period (UTC+2) or standard time period (UTC+1).

Resolution

Understand the distinction between the three pairs of time-related fields in the REST API:

1. startDate / endDate (Calendar Range): Binds the total lifespan of the recurrence. Interpreted as midnight in the designated timezone and returned as a UTC date.
2. between_start / between_end (Daily Window): A configurable HH:MM window restricting when runs trigger. Input as local time but returned as UTC. These automatically adjust for DST shifts based on the date of execution.
3. start_time / end_time (Historical Records): Factual timestamps recording exactly when a run occurred. These are always recorded and returned in strict UTC and do not adjust for DST.

Best Practices:

1. Always explicitly define the timezone property in the REST API JSON payload to ensure the Engine interprets the execution window correctly relative to local time.
2. Use start_time and end_time for factual reporting of past runs.
3. Expect between_start and between_end to fluctuate in UTC output if the period spans a DST change.

Subscribe to this article for updates on execution behavior.

For further assistance, see Contact Broadcom Support.