fix: Derive NetworkTransform interpolation time from the server clock

A NetworkTransform state's SentTime comes from its NetworkTick, which is a
server tick, but the render time the interpolators were given was derived from
LocalTime. That mixes two clocks. LocalTime leads ServerTime, so subtracting
the tick latency from it lands the render time back at approximately ServerTime
rather than a whole tick latency behind it, and a state's SentTime is floored to
a tick boundary on top of that. The render time therefore sat at or ahead of the
newest state that could exist and the interpolator had nothing to interpolate
towards.

Measuring from ServerTime makes the offset the whole tick latency instead of
whatever is left of it, and is self correcting: as the round trip time grows the
tick latency grows and the render time moves further back with it. This also
matches the rest of the component, which already resets the interpolators using
ServerTime.

This is a no-op on a host or server, where the two clocks are the same, so it
only affects clients.

GetTickLatencyInSeconds returns an absolute time rather than a duration and had
the same defect, so it now derives from ServerTime as well. GetTickLatency is
left alone because it returns a tick count rather than a point in time.

Author: NoelStephensUnity

com.unity.netcode.gameobjects/CHANGELOG.md

@@ -19,27 +19,22 @@ Additional documentation and release notes are available at [Multiplayer Documen
   - `Unity.Netcode.Editor.PackageChecker` → `Unity.Netcode.GameObjects.Editor.PackageChecker`
   - `Unity.Netcode.Editor.Tests` → `Unity.Netcode.GameObjects.Editor.Tests`
 
-
-
 ### Deprecated
 
-
 ### Removed
 
-
 ### Fixed
 
+- Issue where non-authority `NetworkTransform` instances derived their interpolation time from the local clock instead of the server clock that state updates are stamped on, which starved the interpolator and reduced interpolation to snapping between state updates. (#TBD)
+- Issue where `NetworkTransform.GetTickLatencyInSeconds` returned a time derived from the local clock, which did not match the time the interpolators actually use. (#TBD)
 - Issue with not being able to spawn initially disabled in-scene placed objects. (#4093)
 - Issue with pre-instantiated network prefab instances being marked as in-scene placed. Now pre-instantiated network prefabs are dynamically spawned. (#4093)
 - Issue where a user could spawn runtime created `NetworkObject` that has a GlobalObjectIdHash of zero. These are not valid instances and will no longer be allowed to spawn. (#4093)
 
-
 ### Security
 
-
 ### Obsolete
 
-
 ## [2.13.1] - 2026-07-19
 
 ### Added

com.unity.netcode.gameobjects/Runtime/Components/NetworkTransform.cs

@@ -4259,14 +4259,27 @@ internal BufferedLinearInterpolatorQuaternion GetRotationInterpolator()
         // Non-Authority
         private void UpdateInterpolation()
         {
-            // Use the local time because:
-            // Client-Server:
-            // Local time is server time on a host or server.
-            // Local time on clients takes latency into consideration.
-            // Distributed authority:
-            // Local time is used by the authority.
-            // Local time on non-authority takes latency into consid]eration.
-            var timeSystem = m_CachedNetworkManager.LocalTime;
+            // Use the server time, because that is the clock the measurements being interpolated between are
+            // stamped on: a state's SentTime is derived from its NetworkTick, which is a server tick.
+            //
+            // Deriving the render time from LocalTime instead mixes two clocks. LocalTime leads ServerTime by
+            // roughly the tick latency, so subtracting the tick latency from it lands the render time back at
+            // (approximately) ServerTime rather than behind it. "Approximately" is the problem: the lead is
+            // fractional while the subtraction is a whole number of ticks, and a state's SentTime is floored to
+            // a tick boundary on top of that. The render time therefore ends up at or slightly ahead of the
+            // newest state that can exist, leaving the interpolator with nothing to interpolate towards. A
+            // measured session had the render time ahead of ServerTime on 100% of frames, with the interpolator
+            // never holding more than one measurement.
+            //
+            // Measuring from ServerTime instead makes the offset the whole tick latency rather than whatever is
+            // left of it, which is self correcting: as the round trip time grows, NetworkTimeSystem.TickLatency
+            // grows and the render time moves further back with it.
+            //
+            // Note this is a no-op on a host or server, where LocalTime and ServerTime are the same.
+            // TODO-JIRA-TICKET:
+            // Confirm the distributed authority case. Authority instances interpolate nothing, so this should
+            // not reach them, but ServerTime's meaning under a CMB service session should be verified.
+            var timeSystem = m_CachedNetworkManager.ServerTime;
             var currentTime = timeSystem.Time;
 #if COM_UNITY_MODULES_PHYSICS || COM_UNITY_MODULES_PHYSICS2D
             var cachedDeltaTime = m_UseRigidbodyForMotion ? m_CachedNetworkManager.RealTimeProvider.FixedDeltaTime : m_CachedNetworkManager.RealTimeProvider.DeltaTime;
@@ -4730,7 +4743,7 @@ internal static float GetTickLatencyInSeconds(NetworkManager networkManager)
         {
             if (networkManager.IsListening)
             {
-                return (float)networkManager.LocalTime.TimeTicksAgo(networkManager.NetworkTimeSystem.TickLatency + InterpolationBufferTickOffset).Time;
+                return (float)networkManager.ServerTime.TimeTicksAgo(networkManager.NetworkTimeSystem.TickLatency + InterpolationBufferTickOffset).Time;
             }
             return 0f;
         }