One-hour time offset in SAM 26.0.5 after DST change (SAMZONEOFFSET)

Symptoms

After a Daylight Saving Time (DST) change, OpCon Schedule Activity Monitor (SAM) on version 26.0.5 can display an offset that is one hour off. SAM itself still schedules correctly.

You may see the wrong offset in:

• Solution Manager / Enterprise Manager (EM)

• The frequency forecast

• Machine offsets from SAM

Applies to

SAM 26.0.5, Windows and Linux. Time zones that do not observe DST (such as Arizona, Hawaii, and most of Asia) are not affected.

Cause

SAM only rewrites its stored UTC offset when the time zone ID changes, and a DST change does not change the ID. SAM keeps the offset in OPCON_INFO under the key SAMZONEOFFSET.

After the fall-back, the value stays at the DST offset. For example, Central Time stays at -5 instead of -6. In Southern Hemisphere zones, which moved into DST in October, the value stays at the standard offset instead. Restarting SAM does not fix it. The API and UI read this stored value, which is why they show an hour off.

Workaround

Set SAMZONEOFFSET to the correct current offset for your time zone. No SAM restart is needed. Have your database administrator run these steps against the SAM database.

1. Confirm your time zone and the current offset:

SELECT INFO_KEY, INFO_VALUE FROM OPCON_INFO WHERE INFO_KEY IN ('SAMTIMEZONE', 'SAMZONEOFFSET')

2. Find your zone in the table under Offset values by time zone and note its stale and correct values. On a Linux SAM, SAMTIMEZONE holds the IANA name (for example, America/Chicago) instead of the Windows zone ID. Match your IANA name to the corresponding Windows zone ID in the table (for example, America/Chicago is Central Standard Time).

3. The correct value is your time zone’s current offset from UTC. Before running the update, confirm the value in the table matches your zone’s offset today. In the update below, replace each placeholder, including the < and >, with your value. Keep the single quotes. For example, '<STALE_VALUE>' becomes '-5'. For <YOUR_SAMTIMEZONE_VALUE>, use the SAMTIMEZONE value exactly as it appears in your step 1 results. Then run the update. It only changes a stale value for the matching zone, so it is safe to re-run.

DECLARE @zone nvarchar(100) = '<YOUR_SAMTIMEZONE_VALUE>';  -- SAMTIMEZONE value
DECLARE @stale varchar(10)  = '<STALE_VALUE>';             -- stale value from table
DECLARE @correct varchar(10) = '<CORRECT_VALUE>';          -- correct value from table
UPDATE OPCON_INFO SET INFO_VALUE = @correct
WHERE INFO_KEY = 'SAMZONEOFFSET' AND INFO_VALUE = @stale
  AND EXISTS (SELECT 1 FROM OPCON_INFO WHERE INFO_KEY = 'SAMTIMEZONE' AND INFO_VALUE = @zone)

4. Re-run the query from step 1 and confirm SAMZONEOFFSET now shows the correct value. Solution Manager / EM, the frequency forecast, and machine offsets then show the right time.

Offset values by time zone

Use the row that matches your SAMTIMEZONE value. Values are hours from UTC. For Northern Hemisphere zones, the correct value is the standard offset. For Southern Hemisphere zones (Australia and New Zealand), the correct value is the DST offset.

Resolution

A permanent fix will be addressed in a future OpCon release before the next time change.

Need Help?

If you need help applying the workaround, open a support case and reference this article. Include your SAM version and the time zone your server is configured for.