# ID3v2.3 YEAR/TDRC not working with mutagen

**URL:** https://community.mp3tag.de/t/id3v2-3-year-tdrc-not-working-with-mutagen/51207
**Category:** Support
**Created:** [December 14, 2020, 11:42pm UTC](https://community.mp3tag.de/t/id3v2-3-year-tdrc-not-working-with-mutagen/51207 "2020-12-14T23:42:00Z")
**Posts on this page:** 11
**Page:** 1

<div class="post-metadata">

### Author: ![swept1](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/c37758/32.png) [@swept1](https://community.mp3tag.de/u/swept1)
#### Post date: [December 14, 2020, 11:42pm UTC](https://community.mp3tag.de/t/id3v2-3-year-tdrc-not-working-with-mutagen/51207/1 "2020-12-14T23:42:00Z")

</div>

I want to start of by saying that I am **unsure** if this is a bug with mp3tag or mutagen.

- When tagging `YEAR` in mp3tag, it does not show up when reading the file in mutagen (`TDRC`, or anything else) unless the tag is specifically in `yyyy` format (where it shows as `TDRC`). I'm not saying it is stripped to `yyyy`, it just doesn't show _at all_. In other words, `yyyy-mm-dd` does not work.
- Conversely, when tagging `TDRC` in mutagen as `yyyy-mm-dd`, mp3tag _can_ read it as `YEAR`.
- Confusingly enough, if I use a third program to read a file tagged by both mp3tag (`YEAR`) and mutagen (`TDRC`), they can both successfully read `yyyy-mm-dd`. So I'm not sure who the culprit is.

This is for ID3v2.3 (confirmed issues on both MP3 and WAV files), and is the only tag I've had this issue with.

Is there some kind of incompatibility here?

* * *

\*Editing with a visual representation:

--  
`yyyy`: mp3tag -\> mutagen

1. 
  - mp3tag input
    - `YEAR=2020`

  - mutagen output
    - `{'TDRC': TDRC(encoding=<Encoding.LATIN1: 0>, text=['2020'])}`

--

`yyyy-mm-dd`: mp3tag -\> mutagen

1. 
  - mp3tag input
    - `YEAR=2020-01-01`

  - mutagen output
    - `{}` _\<-- the bug when using `yyyy-mm-dd`_

  - **expected mutagen output**
    - `{'TDRC': TDRC(encoding=<Encoding.LATIN1: 0>, text=['2020-01-01'])}`

--

`yyyy`: mutagen -\> mp3tag

1. 
  - mutagen input
    - `audio['TDRC'] = mutagen.id3.TDRC(text=["2020"])`

  - mp3tag output
    - `YEAR=2020`

--

`yyyy-mm-dd`: mutagen -\> mp3tag

1. 
  - mutagen input
    - `audio['TDRC'] = mutagen.id3.TDRC(text=["2020-01-01"])`

  - mp3tag output
    - `YEAR=2020-01-01`

--

\*assume `audio` is a file opened with `mutagen.mp3.MP3` or `mutagen.wave.WAVE`

Scenarios 1, 3 and 4 are correct, while 2 seems to be an issue (note the output and expected output). Again I'm not sure if this a problem with mp3tag _writing_ tags or mutagen _reading_ tags

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [December 15, 2020, 5:34am UTC](https://community.mp3tag.de/t/id3v2-3-year-tdrc-not-working-with-mutagen/51207/2 "2020-12-15T05:34:22Z")

</div>

> [@swept1](#):
>
> So I'm not sure who the culprit is.

Mutagen is. MP3tag shows whatever the contents of that field is.  
On the other hand: YEAR is supposed to be nothing but a 4-digit-number, so mutagen complies with the standard. The format with more than just 4 digits is, if you follow the id3 standard, an invalid format.  
So I would say that one should not expect programs to work with invalid input.  
If you need more information about date and time, try RELEASETIME.

---

<div class="post-metadata">

### Author: ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [December 15, 2020, 5:43am UTC](https://community.mp3tag.de/t/id3v2-3-year-tdrc-not-working-with-mutagen/51207/3 "2020-12-15T05:43:26Z")

</div>

Maybe you also have a look at this:

> [@DATE vs YEAR](https://community.mp3tag.de/t/date-vs-year/9819):
>
> Don't know if it rather should be a bug report so post it here. Recently I've tried to add the following tags to some of my mp3s: DATE = 2010-01-28 YEAR = 2010 (which is pretty logical and consistent from my point of view) I've edited the tags via 'Extended tags' to be as specified above and saved. But then I opened Extended tags again and discovered the following: YEAR = 2010-01-28 YEAR = 2010 I was suspicious about 'mappings' and checked them. There was indeed DATE =\> YEAR mapping. But…

---

<div class="post-metadata">

### Author: ![phw](https://community.mp3tag.de/user_avatar/community.mp3tag.de/phw/32/11831_2.png) [@phw](https://community.mp3tag.de/u/phw)
#### Post date: [December 15, 2020, 9:02am UTC](https://community.mp3tag.de/t/id3v2-3-year-tdrc-not-working-with-mutagen/51207/4 "2020-12-15T09:02:37Z")

</div>

Looks like an issue with ID3 v2.3 to me. Note that there is no TDRC vor 2.3, that is a 2.4 frame. For 2.3 there are two separate frames for year (TYER) and day and month (TDAT) . Not exactly sure how MP3Tag handles this, according to [Tag Field Mappings – Mp3tag Documentation](https://docs.mp3tag.de/mapping) it only uses TYER. If that's the case it would explain why you end up with only the year.

Mutagen on readinga 2.3 file would combine TYER and TDAT and combine it into a TDRC frame. On saving it would split a TDRC frame into TYER and TDAT.

What happens if you save the file with 2020-01-01 in Mp3tag with ID3v2.3 and load it back? Does Mp3tag display the complete data again?

EDIT: Just tested it. Indeed Mp3tag will just write the entire date string, e.g. `2020-01-01`, into TYER, it doesn't use the TDAT at all. Mutagen does not accept a TYER which does not follow the YYYY format, so it doesn't load the data.

If possible (meaning your software and devices can deal with it) I would recommend using ID3v2.4 anyway. Rumours say even current Windows can finally handle that 😃

---

<div class="post-metadata">

### Author: ![swept1](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/c37758/32.png) [@swept1](https://community.mp3tag.de/u/swept1)
#### Post date: [December 15, 2020, 4:09pm UTC](https://community.mp3tag.de/t/id3v2-3-year-tdrc-not-working-with-mutagen/51207/5 "2020-12-15T16:09:35Z")

</div>

> On the other hand: YEAR is supposed to be nothing but a 4-digit-number, so mutagen complies with the standard. The format with more than just 4 digits is, if you follow the id3 standard, an invalid format.

@ohrenkino I don't understand, because:

```
TDRC
   The 'Recording time' frame contains a timestamp describing when the
   audio was recorded. Timestamp format is described in the ID3v2
   structure document [ID3v2-strct].

```

_source:_ [https://id3.org/id3v2.4.0-frames](https://id3.org/id3v2.4.0-frames)

So mp3tag maps `YEAR` to `TDRC`, and `TDRC` is a timestamp format.

---

<div class="post-metadata">

### Author: ![swept1](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/c37758/32.png) [@swept1](https://community.mp3tag.de/u/swept1)
#### Post date: [December 15, 2020, 4:12pm UTC](https://community.mp3tag.de/t/id3v2-3-year-tdrc-not-working-with-mutagen/51207/6 "2020-12-15T16:12:01Z")

</div>

> Just tested it. Indeed Mp3tag will just write the entire date string, e.g. 2020-01-01, into TYER

@phw In which field? When I do this in `YEAR`, mutagen doesn't show this _anywhere_, so IDK where it's being mapped.

edit: Are you saying that mp3tag maps `YEAR` to `TYER` but mutagen is just programmed to show it as `TDRC`?

---

<div class="post-metadata">

### Author: ![swept1](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/c37758/32.png) [@swept1](https://community.mp3tag.de/u/swept1)
#### Post date: [December 15, 2020, 4:24pm UTC](https://community.mp3tag.de/t/id3v2-3-year-tdrc-not-working-with-mutagen/51207/7 "2020-12-15T16:24:57Z")

</div>

update: i think i understand now. let me know if not:

for ID3v2. **3** , mp3tag maps YEAR to TYER (right?), but mutagen will show it as TDRC. so even though TDRC is a timestamp field, TYER (which it is actually mapped to) only accepts yyyy. but if you only use yyyy in YEAR, mutagen will show the year in TDRC, which is confusing since it should show as TYER. so this is on mutagen to fix?

either way, i think i will stick to RELEASETIME for yyyy-mm-dd, and YEAR for yyyy. (or can just upgrade to id3v2.4 and continue to use YEAR)

---

<div class="post-metadata">

### Author: ![phw](https://community.mp3tag.de/user_avatar/community.mp3tag.de/phw/32/11831_2.png) [@phw](https://community.mp3tag.de/u/phw)
#### Post date: [December 15, 2020, 5:06pm UTC](https://community.mp3tag.de/t/id3v2-3-year-tdrc-not-working-with-mutagen/51207/8 "2020-12-15T17:06:26Z")

</div>

Yes, I think you got it right. So in ID3 v2.3 Mp3tag will write whatever you write to YEAR into TYER. But Mutagen will only read read this (and make it available as TDRC) if it follows the specs and includes only a year. That's why Mutagen showed 2020 when you entered 2020 (follows the spec), but nothing if you entered 2020-01-01 (mutagen ignores this. You might be able to instead directly read the TYER tag from mutagen, I'm not sure if it leaves it in or removes it from the data it makes available.

> [@swept1](#):
>
> either way, i think i will stick to RELEASETIME for yyyy-mm-dd, and YEAR for yyyy. (or can just upgrade to id3v2.4 and continue to use YEAR)

Yes, if you upgrade to 2.4 you can just continue using YEAR. Mp3tag will write YEAR to TDRC, which is supposed to contain a complete date and could even hold an additional time entry. So 2020 is valid as well as 2020-01-01, and mutagen will happily read this.

---

<div class="post-metadata">

### Author: ![swept1](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/c37758/32.png) [@swept1](https://community.mp3tag.de/u/swept1)
#### Post date: [December 15, 2020, 5:43pm UTC](https://community.mp3tag.de/t/id3v2-3-year-tdrc-not-working-with-mutagen/51207/9 "2020-12-15T17:43:16Z")

</div>

I am tempted to stay on ID3v2.3 and use `RELEASETIME` instead of `YEAR` on ID3v2.4 because based on what I've seen, 2.4 is not widely adopted. So I thought maybe I can create a mapping in mp3tag that will automatically put anything I store in `YEAR` as `RELEASETIME` (similar to how `DATE` will go to `YEAR` and some of the other remappings) for ID3 files. I only consider this because I have a very mixed library (flac, mp3, mp4, wav), and if I want to tag several files at once, I want to be able to just pick `YEAR` and have it go the appropriate place instead of doing all of the ID3 tags separately and specifying `RELEASETIME`. So would you recommend adding this remapping over upgrading to 2.4?

---

<div class="post-metadata">

### Author: ![phw](https://community.mp3tag.de/user_avatar/community.mp3tag.de/phw/32/11831_2.png) [@phw](https://community.mp3tag.de/u/phw)
#### Post date: [December 15, 2020, 11:53pm UTC](https://community.mp3tag.de/t/id3v2-3-year-tdrc-not-working-with-mutagen/51207/10 "2020-12-15T23:53:28Z")

</div>

I can't really recommend you one over the other. I personally would go with ID3 v2.4. But check that the soft and hardware you use supports it.

If the idea with the remapping works staying with ID3 2.3 is also fine, as you say compatibility is still better (which is a shame in 2020). Maybe it's also sufficient for you to stay with just the year, or maybe Mutagen's inability to make use of the year tag if it is more than just a year is not so important if other tools you use have no issue with it. A lot depends on personal requirements 🙂

---

<div class="post-metadata">

### Author: ![system](https://community.mp3tag.de/uploads/default/original/2X/c/ce7035d426cb755a7916793326d23b465222a407.png) [@system](https://community.mp3tag.de/u/system)
#### Post date: [February 9, 2026, 12:28pm UTC](https://community.mp3tag.de/t/id3v2-3-year-tdrc-not-working-with-mutagen/51207/11 "2026-02-09T12:28:58Z")

</div>


