CFrame orientation not accurate on client?

I am not sure if this is a bug or if this is intentional, but when you set a parts orientation for example 30 on the Z axis in studio and then playtest, on the client it will show 30.002 and the part will be oriented that extra .002. However, when you switch to the server it will display accurately and be oriented correctly.

This happens with scripts as well, for example if you insert a Script into ServerScriptService and type in the following:

--> Spawns a new part with a 30 degree orientation on the Z axis.
local Part ="Part")
Part.Name = "OrientationPart"
Part.CanCollide = false
Part.Anchored = true
Part.CFrame =, 5, 0) * CFrame.fromOrientation(0, 0, math.rad(30))
Part.Parent = workspace

Then when you playtest you will notice it shows the extra .002 on the client but when you switch to the server it will display accurately. However, if you type the above code with a LocalScript inside StarterPlayerScripts and you playtest, it will display accurately on the client as it should. Like I said I am not sure if this is a bug or supposed to be intentional. I tried doing some research on it but couldn’t really find anything so I decided to ask here.

This seems like floating point errors to me. It’s noticeable with things like LinearVelocity and other Vec3 values on objects. I’m not too well-versed on the subject so I may be wrong. It shouldn’t affect much though - is it noticeable to the human eye or just in properties?

It’s noticeable to the human eye and properties, it’s really not much of an issue but it can get annoying because it causes slightly uneven points in builds. I feel like this is a replication issue from the server to the client because on the server it is always accurate but when it comes to the client it is always off by some miniscule amount. This results in me having to write a LocalScript on the client that rounds the CFrame orientation values for each part that had their orientation set on the server.

Odd I just tested this myself in disbelief and you are indeed right… I don’t remember this ever happening before. Usually it would take a few back-to-back CFrame operations on a part to mess up the position and orientation but, in this case, the orientation is off out the get go.