Set Time Zone Configuration (error?)

Got a weird one here. Not important but wondering if it might be a bug…

I wasn’t around at the weekend, but noticed this morning that the controller time is at GMT and not BST as it should be (changes this coming weekend!). (UK based)

The code has been running in the controller for several years and the first few lines in the Powerup Chart are:

//Set Clock GMT/BST times
nErrorNumber = SetTimeZoneConfiguration("GMT,10,0,5,0200/BST2,3,0,5,0100"); //Put here so that if time zone changes 'on the fly' we can do something with it
if (nErrorNumber <> 0) then
        AddMessageToQueue(8, "UTC Time Zone not configured");  //if error send to Controller Message Queue
endif

//Sync time on Power Up
nTimeout = 60;
nErrorNumber = SynchronizeClockSNTP(nTimeout, sNTPServerURL);

//Controller powered up time
nMemRead = ReadNumFromIoUnitMemMap(Home_Control, 0xF0300160, nR1PowerTime);

Now, this would be easier to track if I recorded the original time change every time I do an NTP update (0100hrs), but unfortunately I don’t!!

Has anyone any ideas of why/how this could happen?

Anything I can check?

TIA
Colin J

Hi Colin.
That code all looks good to me. I had to look up the command again to double check your time code abbreviations… They all look good with the one comment that I think GMT is getting depreciated. At some point UTC will take its place. That said, I don’t think Opto has done that yet (or is ever likely to).

My best three guesses are as follows… Do you have PAC Display running with the ‘update controller time’ feature active? The PC might have ticked the controller over.
The other guess your not going to like, but I wonder if someone clicked the PAC Terminal ‘Sync time to PC’ button?
Last guess, is the NTPSserver that you call correct?

But yeah, your right, very odd. I have about a dozen controllers running pretty much the exact same code and firmware version for many years and never had an issue.

Hi Ben,

To answer your questions:

I only talk to the PAC R1 using the Opto22 PAC nodes in Node-RED. No interaction regarding time, only Read and Writes of variables/words.

I am the only one who touches this controller, no-one else knows how!! :rofl: I did click the ‘Sync time to PC’ to get the time right, but only after I had found the problem and everything kicked into life as it should have done when the time is correct. The only computer with Windows (10) loaded is mine (mainly to run PAC Control) and it runs through a Virtual Machine on my Ubuntu 20.04 Focal Fossa, so only connects when I am .

Just done several Strategy restarts and they all fetch GMT/UTC. Did the ntpdate at the same time to check current time.

ntp Server - 0.uk.pool.ntp.org

ntpdate -q 0.uk.pool.ntp.org
2021-10-26 16:25:16.312598 (-0100) +0.001328 +/- 0.013154 0.uk.pool.ntp.org 85.199.214.101 s1 no-leap

As I say, the only thing I could think of is a time change on the 4th Sunday in October instead of the last one (5).

Carried out a Restart and see that the Controller is set to UTC/GMT

‘Sync time to PC’ corrects it to BST

Thanks for the help Ben, much appreciated, thought I was going mad.

I have been looking a bit deeper into my Strategy and find that I get a GMT/BST flag with

//Check GMT/BST
nStatusBST = GetTimeZoneDescription(0, sStatusBST);
nPos = FindSubstringInString("BST", 0, sStatusBST);
if (nPos >= 0) then
  	nStatusBST = 1;
else 
  		nStatusBST = 0;
endif

This call brings back a nStatusBST of 0 suggesting that we are in GMT time despite the SetTimeZoneConfiguration being correct. From the above call, indeed, sStatusBST comes back as GMT Greenwich Mean (40 Char String Variable).

Seems wrong to me if the SetTimeZoneConfiguration is correct.

EDIT: There had been no restarts for many weeks before the error occurred.

EDIT2: This routine is part of an error and logging routine and is called every minute.

Hi Colin,

Thanks for the double helping of extra details.
You sure have a good grip on whats happening.
I just wanted to say that I got a chance to dip into the trouble ticket system here at Opto that the software engineers use and did some digging on time zone issues… There are a few tickets from 2018 and firmware versions 8 and 9… in other words, as we mentioned, this feature has been stable and trouble free for many years.

At this point, I can only suggest that you contact our support team and see if they can dig up some extra information that has escaped me.

Sorry, been out today.

I will assemble the information over the next few days., But of course our BST/GMT change is here this weekend. Need to evaluate that there is absolutely no other reason for a change in Time Zone Config, don’t think so, nut this has been running for years, originally with a ‘Homebrew’ Time Change flow until the new command came out and proved to be stable.

Thank you Beno!

Support has found the problem and raised a ticket to fix the issue.

Thanks to All.

1 Like

Hi Folks,

FYI, just received this from the Nice People in the Product Support Group…

(Paraphrased)
Firmware version R10.4d is now available to correct the issue of:
Time zone set for 5th week may end prematurely

Not tried yet, but just to close the problem.

1 Like