AB PVPlus alarm date/time stamp

So I've got an issue I have yet to figure out. I have a PVPlus standard HMI runtime v12. I've gone into the system and set the date and time and enabled daylight savings time as well. I've created a display called Alarm and am enabling that page to display when there is an alarm (I wanted specialized buttons instead of the regular AB buttons). On that page I've created an Alarm List that is tied to the alarm database. Under the settings of the Alarm List properties I enabled the Message and Alarm Time column. So I have a timestamp with my alarm message text. I do not have anything in the Global Connections for time as I'm trying to use the PV time. I created the runtime and downloaded. But when I enabled an alarm to preview it, the message shows correct but the date/time are both incorrect. The time is a few hours and minutes off and the date is off by about 50 years. It's showing 1974.
Does anyone know what i'm missing here?

What date in 1974? Is it May 24th?

That's an interesting problem !

What is the exact PV+ hardware ? If it's v12 I assume it's a PV+7, but the Series letter might matter with regard to exactly which firmware and operating system are underneath FTView ME.

The Settings menus should be configuring the Windows Embedded OS, the same as if you were using the Data & Time settings on a Windows desktop.

>The time is a few hours and minutes off and the date is off by about 50 years. It's showing 1974.

See if you can put a Time/Date String on your screen along with a button that triggers an Alarm, and see how precisely you can nail down the time difference.

Another question is if your PV+ is connected to a network that has Internet access. I don't think that PV+ terminals automatically try to get out to an Internet time server by default, but I don't know for sure. A DHCP server that also had an unconfigured time server on it, somewhere on your network, might give the PV+ a completely bad time.

The date may have been May 24th of 1974. It was at a customers plant which I'm heading back in about a month to add more equipment and was going to try to get it working then. It's a PVPlus 7 Standard 10" using runtime v12. It's not connected to the outside world. Just to about 6 other Ethernet devices. (1734-AENTR, PF525 drives and my 5069-L306ER processor). When I went into the settings even after rebooting the machine, I double checked the clock and it was set correctly, was thinking it was being overwritten by something. I have yet to exit out to the embedded Windows to check what time it says there. Maybe something I do.
I did put in some tags into the date/time of the PVPlus Global connections but could never get it to read in the PLC or write to the PV from the PLC.
If I can't figure it out when I go back, i'm tempted to just write a timestamp to a string for each alarm and oneshot it when it goes high.

All time systems have a zero epoch. A typical choice is January 1, 1970.

All time systems are relative to their zero epoch. So a common implementation is seconds since 1970-01-01T00:00:00.

There are about π x 10⁷ seconds in a year, so the current time in such a system is about a billion and half seconds (1663424244 = 2022-09-17T14:17:24 +0000; the +0000 is UTC).

May 24th 1974 is one-twelfth of the way from the 1970 epoch to now (1663424244 ÷ 12 = 138618687 = 1974-05-24T09:11:27 +0000).

Bottom line: if the timestamp is stored as increments of 12s since that epoch, but interpreted as increments of 1s since that epoch, we would see the observed behavior.

Usually in these cases (I've dealt with time. A lot.) it's the other way, the factor is 1000 (ms vs. s), or a power of 2 (device clock counters that have 8 or 16 or 20 bits of sub-second resolution).

I'm not saying that is necessarily the case, but the round factor of 12, if that is what it is exactly, is a little suspicious.

Is this a version B PV+7? If so, it is a known bug. Change the time zone to a certain time zone. There is knowledgebase article on this

Thank you AJZ for pointing that out.

There is a specific bug in the Alarm List object that somehow scrambles the date and time shown in that object, and it affects only PV+7 Series B.

The Knowledgebase says that if you change the time zone setting to a different-selection-but-functionally-the-same value, that it will work correctly until the next power cycle.

https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/1135405/loc/en_US#__highlight (Access Level: Tech Connect)

The example they give is dear to me: the OS has a setting for "Indiana East", which is really St. Joseph County in northwest Indiana. That's identical to Eastern Time (UTC-5) as long as you don't have to get to O'Hare from South Bend on time.

The Knowledgebase also suggests that Pacific Daylight Time will work correctly.

I'm old enough to have participated in Y2K readiness projects so no shortcuts, errors, or assumptions related to calendars and clocks really surprise me.

The Knowledgebase suggests that Engineering knows about the problem but doesn't have a fix yet.

I'll try the pacific time zone next time I'm out there. I remember being on base during in my barracks watching Y2K on my computer. Nothing would surprise me that is a known bug with no fix in place yet.