S7-1500 Timezone and DST: Resolving LCD vs TIA Portal Configuration Conflicts

Setting timezone and daylight saving time (DST) on a Siemens SIMATIC S7-1500 CPU can be performed from two independent locations: the TIA Portal Device Configuration > Time of Day property page, and the front-panel LCD of the CPU. The two sources do not always agree, and a third actor — the SET_TIMEZONE instruction executing in the user program — can silently overwrite both. This reference explains the precedence model, the behavior on power cycle, the difference between a hardware-configuration download and a software-only download, and the field-proven procedure to make the timezone/DST configuration deterministic.

1. The Two Configuration Locations and a Third Actor

The S7-1500 holds its time-of-day model in two cooperating areas:

1. TIA Portal Device Configuration — Time of Day — This is the engineering-time setting compiled into the hardware configuration. It is stored in the project and downloaded to the CPU as part of the system data. It includes the local timezone offset, the DST rule (active/inactive), and the DST start/end rule definition.
2. Front-panel LCD — The 6-line or 4-line display on the CPU face allows the operator to navigate to Settings > Time > Time Zone and Settings > Time > DST and modify values at runtime. These values are stored in non-volatile CPU memory and survive a power cycle.
3. User program — SET_TIMEZONE instruction — A third, less obvious writer. When called, this instruction overwrites the active timezone and DST rule from a referenced data block. If the source DB is initialized to NULL (all zero bytes), the call writes a zero offset and disables DST, which manifests as UTC with no DST switching.

The remainder of this article addresses why these three writers produce inconsistent results and how to lock down the configuration.

2. Precedence: Who Wins, and When

Siemens documentation does not state a single global winner; instead, the precedence is event-driven. The following table summarizes the observed precedence for each event.

3. The SET_TIMEZONE Failure Mode (Field-Proven)

The most common root cause of a CPU reverting to UTC at a specific hour of the day is the SET_TIMEZONE instruction executing from a NULL data block. The signature is unmistakable:

• Timezone is correct (e.g., UTC-05:00 EST) immediately after the hardware configuration download.
• At a fixed wall-clock time (commonly 03:00 because of a daily scheduled task), the timezone reverts to UTC and DST switching disappears.
• The DST entries in the LCD are intact but the timezone is shown as "UTC Coordinated Universal Time".

3.1 Inspecting the Data Block

Open the project in TIA Portal, expand Program blocks > System blocks > <your time DB> and check the Initial value column. A NULL DB will show all zeros for the timezone offset, DST rule, and DST start/end structures. When the SET_TIMEZONE instruction is called, the CPU reads the DB and writes those zeros into the active runtime parameters.

The TIA Portal Watch table or a cross-reference to the SET_TIMEZONE instance is the fastest path to the offending call. Search the program for any call of SET_TIMEZONE, SET_TIMEZONE_NORDIC, or the older SET_TIMEZONE from the extended instructions library. If the DB is uninitialized or loaded from a recipe/HMI tag that is blank, the symptom is guaranteed.

3.2 Correct SET_TIMEZONE DB Population

The SET_TIMEZONE instruction expects a structure of type DTL-based timezone rule. The minimum populated fields are shown below.

If the user program is the authoritative writer, ensure the DB is initialized with the correct values at startup (OB100) and not overwritten by a blank HMI tag or an empty recipe.

4. Hardware Download vs. Software Download — Why the Timezone Did Not Update

A frequently observed symptom is "I changed DST in Device Configuration and downloaded, but the DST entries on the LCD are still there." The cause is the download type. TIA Portal distinguishes two download operations:

• Software download — Pushes the program blocks only. The CPU remains in RUN if possible. Time of Day parameters are not transmitted.
• Hardware download (full) — Prompts to STOP the CPU and transmits the system data, including Time of Day.

If TIA Portal did not prompt to STOP the CPU when you downloaded, only software blocks were transferred. The timezone and DST settings you see on the LCD are the unchanged runtime values from the previous download, regardless of what is in the project.

5. LCD Override Behavior (The Persistent Override)

Once the project is loaded and the CPU is in RUN, an operator can change the timezone and DST rule from the front-panel LCD. The CPU applies the change immediately and stores it in non-volatile memory. The key behavior is:

1. The LCD value overrides the compiled hardware configuration for runtime operation.
2. The LCD value persists across warm restart, cold restart, and complete power loss.
3. The next hardware download overwrites the LCD value with the project value.
4. If the project has no Time of Day configuration (the property page is empty or default), the LCD value still persists; it is never auto-cleared.

This explains the "mystery reversion" in the source scenario: a hardware configuration was downloaded, then the operator set the timezone on the LCD to EST. The CPU ran in EST until the next full hardware download, at which point the compiled UTC value replaced EST. No power cycle, no daily schedule, and no user program was involved — the reversion was triggered by a later full download.

6. Time of Day Properties in TIA Portal Device Configuration

The relevant property page is reached via Devices & networks > <CPU> > Properties > Time of Day. The fields are:

The full functional description is published in the Siemens TIA Portal Help under Functional description of S7-1500 CPUs > Setting the operating behavior > Time-of-day functions > Setting and reading the time of day (S7-1500) at docs.tia.siemens.cloud.

7. User-Programmatic Time Reads and Writes

Beyond configuration, the user program can read and write the clock with the following instructions from the Extended instructions > Time library.

For more detail on WR_SYS_T and the read instructions, refer to the same Siemens functional description page linked above.

8. Step-by-Step: Locking Down the Timezone and DST

Use the following procedure when the timezone or DST is observed to drift, revert, or not match the project.

Prerequisites

• TIA Portal V15.1 or later (V20 recommended for current documentation).
• Online connection to the S7-1500 CPU.
• Project archive of the current machine program.

Procedure

1. Open the project, expand Devices & networks > <CPU> > Properties > Time of Day and set the local time, timezone offset, DST active flag, and DST rule to the correct values for the site.
2. Cross-reference the program for any call of SET_TIMEZONE or SET_TIMEZONE_NORDIC. If found, open the referenced DB and confirm the Initial values are populated, not all zero. If the program must change the timezone at runtime, ensure the DB is loaded with valid data in OB100 or before the first call.
3. Right-click the CPU in the project tree, choose Download to device > Hardware and software (only if different). Confirm TIA Portal prompts to STOP the CPU. If it does not prompt, repeat with Download to device > Hardware and software (full).
4. After the download completes and the CPU returns to RUN, navigate the front-panel LCD to Settings > Time > Time Zone and Settings > Time > DST. Confirm the values match the project.
5. Power cycle the CPU (turn off the 24 V supply for 10 seconds, restore). Re-check the LCD. The values should be unchanged.
6. Search the program for any scheduled task (time-of-day interrupt OB, cyclic OB) that calls SET_TIMEZONE. Remove the call if the timezone is not supposed to change at runtime.
7. Document the configuration in the project release notes so that a future software-only download does not invalidate the assumption.

Verification

Create a watch table with the following tags and confirm the values remain stable for at least 24 hours, including across a DST boundary if the schedule permits:

• %DB_TIMEZONE.bias (or the active timezone tag if exposed)
• %DB_TIMEZONE.daylightBias
• %DB_TIMEZONE.standardStart
• %DB_TIMEZONE.daylightStart

Compare the watch table values to the project DB. Any drift indicates a SET_TIMEZONE call executing with a NULL or stale DB.

9. Troubleshooting Matrix

10. Best Practices for Field Deployment

• Pick one source of truth. Either the TIA Portal Device Configuration or the LCD or a runtime SET_TIMEZONE call. Never run all three.
• Never call SET_TIMEZONE from a DB that is loaded from a blank HMI tag or recipe. Initialize the DB with the actual values in OB100, or build the structure from constants in the program.
• Always perform a full hardware download when changing Time of Day. Verify that TIA Portal prompts to STOP the CPU.
• Disable LCD editing in production if the runtime authority is the project. Protect the CPU with a password so that the front-panel settings menu is not user-accessible.
• Document the timezone in the HMI project as well. A mismatch between the HMI timezone offset and the CPU timezone will manifest as a one- or two-hour display error that looks like a DST bug.
• Centralize NTP. If the site has multiple CPUs, configure one as the NTP master or use a plant-wide NTP server via the CP 1543-1. Avoid each CPU drifting independently.

11. Verification Checklist

After applying the procedure in Section 8, confirm each item:

1. Project Time of Day properties show the correct timezone and DST rule.
2. No unconditional SET_TIMEZONE call exists in the program; if one exists, the referenced DB is populated and not overwritten by blank data.
3. Full hardware download performed (TIA Portal prompted to STOP).
4. Front-panel LCD timezone and DST match the project.
5. 24-hour stability test passed — no reversion to UTC.
6. Power cycle test passed — LCD values persist and remain correct.
7. DST boundary test passed (if scheduled to occur within the test window) — clock advances or falls back by exactly 60 minutes at 02:00 local.