# Is RELEASETIME really an ID3v2.3 tag?
**URL:** https://community.mp3tag.de/t/is-releasetime-really-an-id3v2-3-tag/70802
**Category:** General Discussion
**Created:** [March 2, 2026, 8:57am UTC](https://community.mp3tag.de/t/is-releasetime-really-an-id3v2-3-tag/70802 "2026-03-02T08:57:45Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@yorickausyps](https://community.mp3tag.de/u/yorickausyps)
#### Post date: [March 2, 2026, 8:57am UTC](https://community.mp3tag.de/t/is-releasetime-really-an-id3v2-3-tag/70802/1 "2026-03-02T08:57:45Z")
In [Tag Field Mappings – Mp3tag Documentation](https://docs.mp3tag.de/mapping/) the tag RELEASETIME is shown as being both an ID3v2.3 and ID3v2.4 tag TDRL whereas in [id3v2.3.0 - ID3.org](https://id3.org/id3v2.3.0) it can not be found. It first appears in [id3v2.4.0-frames - ID3.org](https://id3.org/id3v2.4.0-frames), and also in [Tag Mapping - Hydrogenaudio Knowledgebase](https://wiki.hydrogenaudio.org/index.php?title=Tag_Mapping#Mapping_Tables) it is mentioned as ID3v2.4 tag only.
I wanted to use RELEASETIME, because it contains a complete date and not only a year. But when I use RELEASETIME in mp3tag with writing ID3v2.3 tags to mp3 files, I therefore get an inconsistent tag in the file. I think the tag should read e.g. TXXX="RELEASETIME 2009-10-12" and not TDRL="2009-10-12". Mp3diags btw. does not find this issue, but with exiftoolgui you can see, that there are v2.3 and v2.4 tag together in the file.
So I don't know what is wrong and what is right. What do you think? Should mp3tag write a user defined tag?
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [March 2, 2026, 9:01am UTC](https://community.mp3tag.de/t/is-releasetime-really-an-id3v2-3-tag/70802/2 "2026-03-02T09:01:05Z")
> [@yorickausyps](#):
>
> Should mp3tag write a user defined tag?
No. Apple introduced this tag field in podcasts also for ID3V2.3. And as it has been adopted also for other podcasts, it should stay like that. Standard fields are much wider accepted than user-defined fields.
The advantage of the current solution is: while the user-defined field always has the name that follows TXXX, a standard field like TDRL can be localized.
So the field RELEASETIME about which we can talk without any ambiguities, would be hard to understand if it would be named locally e.g. "Veröffentlichungsdatum".
Even now various applications have their own naming schemes and data interchange would become virtually impossible for this kind of data.
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [March 2, 2026, 9:15am UTC](https://community.mp3tag.de/t/is-releasetime-really-an-id3v2-3-tag/70802/3 "2026-03-02T09:15:50Z")
> [@yorickausyps](#):
>
> But when I use RELEASETIME in mp3tag with writing ID3v2.3 tags to mp3 files, I therefore get an inconsistent tag in the file
What exactly do you mean?
If I write `RELEASETIME` with the content 2026-03-02 in my test mp3 using the mpeg write option ID3v2.3 UTF-16 I see it exactly that way in my file:
So what do you think is "inconsistent"?
For comparison, this is how it looks with the mpeg write option ID3v2.4 UTF-8:
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [March 2, 2026, 9:40am UTC](https://community.mp3tag.de/t/is-releasetime-really-an-id3v2-3-tag/70802/4 "2026-03-02T09:40:48Z")
@yorickausyps Or are you suggesting that Mp3tag should not write `TDRL` in ID3v2.3 because it is not defined in the official standard?
BTW: The official standard for ID3v2.4 describes timestamps as:
Perhaps I'm mistaken, but I understood that all these time-variants are valid:
yyyy
yyyy-MM
yyyy-MM-dd
yyyy-MM-ddTHH
yyyy-MM-ddTHH:mm
yyyy-MM-ddTHH:mm:ss
**or with examples:**
1987
1987-12
1987-12-31
1987-12-31T23
1987-12-31T23:59
1987-12-31T23:59:59
---
### Author:  [@arb](https://community.mp3tag.de/u/arb)
#### Post date: [March 2, 2026, 4:11pm UTC](https://community.mp3tag.de/t/is-releasetime-really-an-id3v2-3-tag/70802/5 "2026-03-02T16:11:16Z")
I’ve noticed it’s supported in Windows File Explorer by Matroska files using the “Date released” column.
~~.mp3’s set to use IDv2.4 no longer show `YEAR` like with v2.3 but they **do** show `RELEASETIME` in both “Year” and “Date released”.~~
.mp3’s actually fill in the "Year" column from either `YEAR` or `RELEASEDATE`:
- with ID3v2.3 tags, it prefers `YEAR` as long as it's formatted correctly.
- with ID3v2.4, it'll prefer the "newest" stated date between the two tags.
- If `YEAR`'s missing, it'll use `RELEASETIME` (and obviously vice versa).
`RELEASETIME` is always required for “Date released” for the formats shown to support it.
`DATE`’s a stranger one as it’s only supported by .flac and is the only time-formatted tag supported for .opus. This is just from File Explorer, mind you.
* * *
`YEAR` = 1000
`RELEASETIME` = 2000
`DATE` = 3000
---
### Author:  [@yorickausyps](https://community.mp3tag.de/u/yorickausyps)
#### Post date: [March 3, 2026, 5:35pm UTC](https://community.mp3tag.de/t/is-releasetime-really-an-id3v2-3-tag/70802/6 "2026-03-03T17:35:12Z")
Thank you all for your contributions. Now I think it is OK to use RELEASETIME in ID3v2.3 tags, because Apple does it and Microsofts Windows does it also. Currently I'm looking for apps that also can properly use a RELEASETIME tag in mp3 files with ID3v2.3 tags. So far I have only found musicbee to display its content correctly.
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [March 12, 2026, 7:07am UTC](https://community.mp3tag.de/t/is-releasetime-really-an-id3v2-3-tag/70802/7 "2026-03-12T07:07:30Z")
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.