Fix SourceTimestamp and ServerTimestamp mismatch in ServerStatus children

[Copilot]

Proposed changes

Fixes the timestamp mismatch issue where SourceTimestamp and ServerTimestamp of ServerStatus children variables (CurrentTime, StartTime, State, etc.) were not equal in stack v1.05, restoring the v1.04 behavior.

Problem

Both CoreNodeManager and CustomNodeManager were setting ServerTimestamp to DateTime.UtcNow early in read operations, before calling node read callbacks. The node callbacks (e.g., OnReadServerStatus) would then set SourceTimestamp to a different DateTime.UtcNow value, causing timing mismatches (typically ~1ms difference).

Solution

• Modified CoreNodeManager.Read to initialize ServerTimestamp to DateTime.MinValue and synchronize it with SourceTimestamp after reading
• Applied the same fix to CustomNodeManager.Read which handles ServerStatus and other diagnostic nodes
• For Value attributes, ServerTimestamp is now set equal to SourceTimestamp after the node's ReadAttribute call
• For non-Value attributes, only ServerTimestamp is set (as SourceTimestamp is not used for these)

Changes Made

• Libraries/Opc.Ua.Server/NodeManager/CoreNodeManager.cs: Fixed timestamp synchronization for Value attributes
• Libraries/Opc.Ua.Server/Diagnostics/CustomNodeManager.cs: Applied same fix for diagnostic nodes including ServerStatus
• Tests/Opc.Ua.Server.Tests/ReferenceServerTest.cs: Added ServerStatusTimestampsMatchAsync test to verify timestamps match for ServerStatus children

Related Issues

• Fixes From stack v1.04, the SourceTimestamp of the children variables of ServerStatus variable is not equal to ServerTimestamp. Is this behavior expected? #2771

Types of changes

What types of changes does your code introduce?

• Bugfix (non-breaking change which fixes an issue)
• Enhancement (non-breaking change which adds functionality)
• Test enhancement (non-breaking change to increase test coverage)
• Breaking change (fix or feature that would cause existing functionality to not work as expected, requires version increase of Nuget packages)
• Documentation Update (if none of the other choices apply)

Checklist

• I have read the CONTRIBUTING doc.
• I have signed the CLA.
• I ran tests locally with my changes, all passed.
• I fixed all failing tests in the CI pipelines.
• I fixed all issues with CodeQL and LGTM.
• I have added tests that prove my fix is effective or that my feature works and increased code coverage.
• I have added necessary documentation (if appropriate).
• Any dependent changes have been merged and published in downstream modules.

Further comments

Testing Results:

• All existing tests pass (156/156)
• New test ServerStatusTimestampsMatchAsync passes (1/1)
• Total: 157/157 tests pass

The fix ensures ServerTimestamp and SourceTimestamp are always synchronized for ServerStatus children, matching the behavior from stack v1.04.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>From stack v1.04, the SourceTimestamp of the children variables of ServerStatus variable is not equal to ServerTimestamp. Is this behavior expected?</issue_title>
<issue_description>### Type of issue

• Bug
• Enhancement
• Compliance
• Question
• Help wanted

Current Behavior

From stack v1.05, the SourceTimestamp and ServerTimestamp of the children (CurrentTime for example) variables of ServerStatus variable are not equal.

Expected Behavior

Like in stack v1.04, the SourceTimestamp and ServerTimestamp of the children (CurrentTime for example) variables of ServerStatus variable should be equal.

Steps To Reproduce

No response

Environment

- OS:Windows11
- Environment: VS2022
- Runtime:.NET 4.6.2
- Nuget Version:
- Component:
- Server:Reference Server
- Client: UA Expert

Anything else?

No response</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes From stack v1.04, the SourceTimestamp of the children variables of ServerStatus variable is not equal to ServerTimestamp. Is this behavior expected? #2771

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ marcschier
❌ Copilot
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[romanett]

@copilot please contiune working

[Copilot]

@copilot please contiune working

I've implemented a fix that sets ServerTimestamp equal to SourceTimestamp after node read operations in CoreNodeManager. The change ensures both timestamps are synchronized for nodes like ServerStatus children.

Changes made (9ddb9ba):

• Modified CoreNodeManager.cs to set ServerTimestamp = SourceTimestamp after reading values
• Added a test case to verify timestamp matching

Current status:
All existing tests pass (156/156), but the new test reveals there's still a small timing discrepancy (~1ms) between the timestamps. I need to investigate further to understand why the timestamps aren't matching exactly despite the assignment. There may be multiple node managers processing the same node or the timestamps are being modified after my code runs.

Continuing investigation...