This problems is very real, and is actually two problems. One problem might be a mystery, but the second seems like a bug that, if fixed, would make the first problem easier to ignore.
PROBLEM #1 Sometimes the YEAR field gets a full date in it. This should not happen, and I haven't found when/why this happens. The 4 digit year was typed in the YEAR field, but MC then added the current day and month and stored the full date. The problem isn't obvious because the full date is not visible in a view's YEAR column, but is definitely there. This has happened to many but not all of my tracks, some tagged years ago, but it did not become visible until MC19 and MC20. The only fix, once I find this, is to re-enter the YEAR field value, sometimes it takes 2 or 3 tries to get it to stick. But the first challenge is finding which YEAR fields have this problem.
BUG #2: Visualization web field TRACKINFO_INSERT_YEAR does not actually display just the YEAR, it displays whatever is in the YEAR field. So, when the problem has put a full date in the YEAR field, that's what is displayed in the visualization. If TRACKINFO_INSERT_YEAR could actually extract and show ONLY the YEAR, visualizations would not be broken due to problem #1. It seems that this behavior was changed, possibly in MC19 and now in MC20, to show the entire field's content without parsing for just the YEAR portion.
One theory: I often use MC15 for tagging music files, because it's the last MC version that allowed fast, efficient list tagging rather than the multi-click "search" behavior. But my playback, and other uses, is MC20. Could the YEAR bug arise because of different behavior across MC15 and later versions? If so, I never saw the problem until I started playing tracks with MC19 and MC20.
Editorial: I treasure having MC15 on my main music editing/tagging PC, mind-boggling how clumsy later versions are.