"No that field is not part of the ID3 tag standard and is thus not stored internally in the files and must be stored externally in the MC sidecar. So moving the file outside of MC will cause that info to be lost."
or:
"Yes that field is part of the ID3 tag standard and should be getting stored internally within the file. There must be a bug in are storing code for that particular field. Thanks for pointing this out."
One thing your examples point out one thing that you may not understand about the core functionality of MC: It
never uses the in-file tags (or sidecar metadata) after importing the files.
Never.
Media Center is a database (they call the "database" the "Library"). The Library is all that matters during regular operation of MC. You can set any field (at least the vast majority of them) to
also save the data out to tags in the files, but in general once you've imported the tracks, the only times this would be used is if you then import the files into a different copy of MC (or, at least, a different Library).
That's simplifying a bit because if you set Auto-Import up to do so, you can have it "detect" external changes to the files and update the Library to correspond. But the general idea holds: The Library is the source of "truth" and MC always stores the data it uses there, and then sometimes, optionally, syncs this data to the tags (or sidecars, which are the same thing for "untaggable file types"). But those tags are really only used for "interchange" with other applications.
Note: That's also why you don't want to move files outside of MC if you can avoid it, because then the database in MC is left with a "broken" file (that points to no file on disk anymore) and when it imports the file in the new location, it will (in some cases at least) re-import it from scratch. Auto-Import does try to "detect" moved files and "fix" them (if you have this option enabled), but this only works if you leave them relatively unchanged (moving whole directories and not changing the file names inside the directory). Anything it can't auto-match, it will remove the old broken link and re-import found files as "new".
You may have understood that, maybe not, but it was worth making clear.
The other thing is about the ID3 tag standard. MC will store ANY field into tags (for supported file types) if you tell it to, including custom fields. So, even if you make up your own custom fields with names you created, you can have these saved to the ID3 tags in a MP3 file (or the comparable tags in APE or FLAC files). It doesn't matter if the field is one of the original, predefined tags supported in the ID3 spec.
Of course, custom tags like that are basically only going to be usable in another copy of MC, because no other program will know about them. But, it'll still save them if you tell it to save to tags when you define the custom field.
Moving on, Dates are pretty weird. MC uses the floating point number internally to store date values. ID3 (and, really, any text-based tag system) doesn't handle floats. So, the way dates and times, at least for many of the standard fields, are defined in the ID3v2.4 spec is to use two separate tags (one for the date and one for the time). The Time format for the stored strings in the tags is specified in this document:
https://id3.org/id3v2.4.0-structureI'm honestly not sure how MC maps and stores its various date-related fields in the ID3 tags. I know it can interchange Last Played and other similar "standard" fields with other applications (like iTunes), but I've never bothered to look at how they're actually stored in the files. And, it sounds like, from above, maybe the special Date (Release) field is broken in some way at how it does map it to the in-file tags.