Currently, beets stores incomplete dates (and original dates) as valid dates, so a release where only the year (or year and month) are known, is stored as having a valid date of, say 2019-01-01 or 2019-09-01.
The problem with this is it messes up queries and lots of albums/tracks seem to have been released on January 1 of each year.
MySQL, for instance, has always allowed storing “incomplete dates”, like
0000-07-19 (birthday July 19, year unknown)
2019-09-00 (somewhen in September, 2019)
2019-00-00 (somewhen in the year 2019)
Does SQLite also offer this feature? It would be very helpful to substitute 00 instead of 01 for a month or day part unknown, instead of aggregating everything on a valid, but wrong date.
Hi! Can you clarify what you mean by “stores”? That is, how did you reach the conclusion that beets stores dates this way?
The beets data model actually works by storing the year, month, and day separately, in different SQLite columns. So I’m not quite sure what you’re seeing here.
I was actually trying to find the problem in Date queries malfunction? and just imported/beet infoed some files which had tags of “2019” for date and/or originalyear and got displayed as originaldate: 2019-01-01 so I was assuming you used an SQLite date field.
The problem is still: Storing (or showing) an album that might have been released in September, 2019 under a date of 2019-01-01. Which is a valid date but wrong.
Aha, you’re just looking at a pseudo-field that tries to summarize all the components as one Python date object. No need to worry about wrong data—the underlying information is still correct and hasn’t manufactured “ones.”
One less worry, ok. But still it should (if possible) create queryable data that is correct (i.e., don’t show 2019-01-01 if it’s really somewhen in 2019 and notJanuary 1st, 2019.
You say it’s using a Python date. I wonder how complicated it would be to extend the class used to facilitate dates like 2019-00-00. Or at least display00 instead of a valid month or day, to indicate that these are missing.