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
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 not
January 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 display
00 instead of a valid month or day, to indicate that these are missing.