Are you perhaps using delta transforms? Or parenting?

Nope, and nope.

These values are produced by converting the Euler XYZ rotation of two objects to Quaternions and back to Euler XYZ rotation. So these are simply "rounding errors". The answer below answers your question from my point of view (at least considering the title of the question). Please explain exactly what you want to do here (or ask a new question). Which object or which rotation do you want to "convert" here?

@quellenform Well, no these are not simply rounding errors - it's rotation relative to a different frame of reference, in this case the rotation of the GN object, like if you have set up a custom transform orientation. He is wondering why the relative Y value is not 0°, although the object is rotated 0° on Y in global coordinates and the "custom orientation" is also 0° on Y in global coordinates. The answer is: because both being 0° globally does not mean they are 0° relative to each other when the other axes are not 0°.

I've deleted my answer though because I was editing it to make an elaborate explanation but then he commented, with what math nodes he could convert to relative - and that leaves me wondering, what he actually means? What is "convert to original" in this case? Original to the world, original in relation to the GN object? Or does he simply want the absolute difference by subtracting the values as he expects at one point in his question...? And why not simply use the node set to Original if he wants the original values? To much unclear and for none of these things you actually need my answer.

@GordonBrinkmann Maybe I haven't looked at it as closely as you have and my assessment is wrong, but to my knowledge a conversion of Euler XYZ, (of two objects! ...in which the world coordinate system is used as the base) and in which X and Z have been changed, results in a recalculation of the XYZ rotation and this leads to rounding errors. I may be wrong. But if you reset the rotation of the base object to (0,0,0), then the value for Y will also be 0.

@GordonBrinkmann ...and yes, it's definitely an XY problem

@quellenform The relative values in the node are based on local coordinates of the GN object, not the world. Therefore both having a global 0° rotation on one axis does not mean one is rotated relative 0° based on the other object (this is true for each of the axes). Say you have cube1, rotate it (25°, 0°, 60°) and cube2 rotated (45°, 0°, -30°). Now parent cube1 to cube2 with Object (Keep Transform Without Inverse). Visually nothing changed, but cube1 now shows a rotation of (25°, 45°, 90°). A bit too different for a rounding error. But as you said, XY problem and I gave up on this.

@GordonBrinkmann Yes, I (once again) completely misunderstood the question ...and I'm obviously not the only one here :D

It's not even just what Brinkmann is saying (although that is correct); and, quellenform is correct that there should be rounding errors, even though that's only a small part of the explanation. It's also, this is fundamentally the wrong way to interpret Euler components. An object's rotation consists of all 3, sequential, rotations. The output is not necessarily the input, because aliasing. And the axes are not independent rotations, but dependent on the other channels.

@GordonBrinkmann I updated the question and wrote what I need to find exactly.

Sorry, I do not understand what you are trying to do. You say you want to replicate the Texture Coordinate > Object output. Usually this Texture Coordinate node is used in a material for an object for example to get a gradient as I suppose from the naming in your file. So on which object you want to use the coordinates, and which object should they be taken from? You store a lot of named attributes on two objects but do not use them.

@GordonBrinkmann. I did not recreate a shader node group in that file. I just showed how I'm trying to replicate Teture coordinate in GN. In shaders, I'll just put the attribute in the mapping instead of "object" output. Just tell me, do you know how to get the relative rotation from the original loc and rot of "gradient" and "main object"? What math operations are going on inside the obect info node to get the relative data?

Sorry, this site is not supposed to have long discussions in the comments. I know you did not create a shader in GN. What I mean is, in a shader it is usually quite clear where and how to use the coordinates - but I do not see you using them anywhere so I do not know what you are trying to do. Relative rotation - relative to what? Gradient relative to main or vice versa? Or relative to the controller? And what do you mean by "get the relative rotation"? Get like seeing the values written somewhere or like getting an output providing them to plug them in somewhere?

Relative rotation of "gradient" to "main object". From "controller", through attribute, we get original loc and rot of "gradient" and transfer it to GN of "main object".

in general, you don't see rounding errors until they accumulate. So if you have a chain of a 1000 parentings, the grand-grand-grand...-child might have visibly wrong orientation than the one it should have if not for the limited floating point accuracy. I guess you could get visible rounding errors much more easily: just add 360°×1'000'000'000'000'000 to each rotation, which should have no effect, but numerically will shift the float precision, therefore removing last digits of the sum.

There's another thing that I don't call a rounding error, and it's the fact that you lose the information about the number of rotations when converting to quaternions, so if you take a <360°, 0, 0> Euler, convert it to a quaternion and back, you end up with <0, 0, 0> Euler, but this seems irrelevant to OP's case.

The issue OP has is he doesn't understand that Euler rotation happens in order and therefore acts like rotating the axes of rotation (keep in mind on the gif it's XYZ, so the Y axis is rotated after the monkey is rotated around this axis) i.imgur.com/WeXqRZ7.gif

To clarify the "acts like": i.imgur.com/Eno9pdW.gif

@GordonBrinkmann Relative rotation of "gradient" to "main object". From "controller" we get original loc and rot of "gradient" and transfer it, through attribute, to GN of "main object".