Daylight Savings Time (DST)

My Gateway shows the proper time, but the tag historian is still logging an hour back. I rebooted the gateway, and the problem did not go away. The gateway shows the proper time, the local computer running the gateway shows the proper time (I assume that is where the gateway is pulling it from anyhow), the PLC's generating the tags show the proper time, though I assume that is irrelevant anyhow.

I am sure I am missing something. Any help would be appreciated.

What is the time on the server where the Historian Database is located?

It is all on the same local PC, sorry. So, Databases are local, Gateway is local.

Are your PLCs connected via Ignition native drivers, or via OPC UA connections? If the latter, they do get their timestamps from the PLC.

They are linked under OPC UA Device Connections, but the PLC time is also correct. It was off, I adjusted it, then I verified gateway was proper time stamp, then rebooted the gateway.

Is the PLC's timezone/DST status correct? It could still be giving you a hour offset in UTC, which is how OPC transfers all timestamps. (As does Ignition, internally.)

(U.S. time changed this weekend, so your problem is suspicious.)

Yes, it is using UTC -5 (Eastern time zone) and then has Adjust for DST checked to do the +1.

Technically, I am determining my dateandtime is wrong because I did the following:

 SELECT CAST(DATEADD(SECOND, (t_stamp/1000) - 18000
 ,'1970/1/1') AS DateTime)

I suppose I am assuming that -18000 should still be correct before/after DST because the gateway adjusted its time automatically, but I am thinking I am wrong.

MS SQL Server? Its datetime columns don't carry time zone information. If you are using those in a timezone-aware application, you've screwed up. (IMNSHO, if you are using MS SQL Server at all, you've screwed up. But this particular case is an extra screw up.)

1 Like

What happens if you retrieve the data from the historian using the system.tag.* functions (as you should be anyway), and then convert the t-stamp using system.date.fromMillis() function.

This does appear to be the case, but this would be my first DST crossing since getting my feet wet in this stuff, so as long as learning occurs, I suppose extra-screw ups can be good long term... lol.