Resolving Ignition Perspective urlParams Timestamp Mismatch

Which clock stamps a Perspective property write?

The clock that stamps a write belongs to the node that builds the qualified value (QV). A QV carries three fields: value, quality, and a UTC timestamp. Whichever node wraps a bare value into a QV writes its own clock into that timestamp.

Follow the packet. When a browser, the Designer, or Workstation writes to a session, view, or component property, the client builds the full QV locally and sends it to the gateway. The timestamp is the client's UTC clock at that moment. page.props.urlParams takes a different path. URL parameters arrive at the gateway as bare values, because they come from the URL during page load and navigation. The gateway wraps them into QVs, so they get the gateway's UTC clock. That still holds when you later write urlParams from a client. The property keeps its gateway-side handling, even though the design assumes it is read-only.

Workstation clients are expected to follow the browser path. Run the check in the third section below to confirm this on your own installation.

If the clocks agree in UTC, the two paths produce timestamps that are effectively identical and nobody notices. The mismatch only becomes visible when the client clock has drifted from the gateway clock.

Check: confirm that the mismatch you see is on urlParams only. If view and component props written in the same client event also disagree with each other, you have a different problem.

Is the client clock actually off from the gateway?

Layer one first. For timestamps, that means the time source. A difference in time zone does not matter here, because QV timestamps are UTC. The only thing that matters is true skew from real time.

1. Read the gateway host's UTC time and its time sync status from the OS. On Windows, w32tm /query /status shows the configured source and the last successful sync.
2. Read the same values on the Designer workstation or the browser client machine.
3. Compare both machines against the same reference, not against each other by eye.
4. Record the offset in seconds. This offset is the error you will see between urlParams timestamps and client-stamped prop timestamps.

Check: if the offset is close to zero, the timestamp difference between scopes should also be close to zero. If the difference is large while the clocks agree, go to the next section before you touch NTP.

How do you prove which node stamped a value?

Build a controlled write that sends the same value down both paths from a single client event.

1. On a test view, add a button with an action that writes one value to page.props.urlParams (use a test key) and to a custom property on the view.
2. Trigger the action from the Designer in preview mode, then again from a browser session.
3. Read the QV timestamp of each property and log both. A gateway-side reference, such as a gateway-scoped script logging the gateway's current time, gives you a third timestamp to compare against.
4. Compare the results:
   • The urlParams timestamp should track the gateway reference.
   • The view prop timestamp should track the client clock.

Check: the measured timestamp delta between the two props should equal the clock offset from the previous section. Once it does, the mechanism is confirmed for your system.

How do you remove the dependency on which clock stamped the value?

There are two separate fixes. Apply both.

1. Synchronize the clocks. Point the gateway and every engineering and operator client to the same time source. Engineering laptops that run the Designer are the usual offenders, because they sit off the plant domain or sleep for days. After sync, the client-stamped and gateway-stamped timestamps converge.

2. Stop comparing QV timestamps across scopes. Sync reduces the error but does not remove it, because any client can drift again. Treat the QV timestamp as "when this node last wrapped the value," not as "when the event happened." Where the logic depends on event time, stamp it explicitly from one clock.

1. Add a dedicated timestamp property (for example, a custom view or session property) that holds the event time.
2. Populate it from one authority. For audit and cross-client ordering, use the gateway, for example by sending a message to a gateway-scoped handler that returns or writes gateway time.
3. Drive change scripts, sorting, and "which is newer" comparisons from that property, not from urlParams or component QV timestamps.
4. Keep QV timestamps for diagnostics only, such as "when did this binding last update on this node."

Check: skew the client clock deliberately on a test machine. Logic that uses the explicit timestamp property should behave the same. Logic that still reads QV timestamps will shift by the size of the skew.

Which recurring pitfalls reintroduce the mismatch?

Check: search the project's scripts and bindings for any read of property timestamps. List each one and the scope it reads from.

How do you verify the whole path end to end?

1. Confirm the gateway and all client hosts report a near-zero UTC offset against the common time source.
2. Re-run the probe action from the Designer, a browser, and Workstation. The urlParams timestamp and the view prop timestamp should now agree within the residual sync error.
3. Trigger the real workflow that exposed the problem. Confirm that ordering and elapsed-time logic read from the explicit gateway-stamped property.
4. Offset one test client's clock by a known amount and repeat step 3. The workflow result must not change. The only difference should be the raw QV timestamp on client-stamped props, and it should differ by exactly the offset you applied.

FAQ