Time for me to go back to a very boring error in the Discogs database: release dates. In an earlier post I already wrote about weird data in the Released field (this is the date field) but that is not what I want to talk about now (as I have already done that). This time it is about something a lot simpler: wrong months in Discogs.
This happens only for older releases that haven't been updated for years. It can be argued that this is mostly a cosmetic bug as the old dates with month values of 00 will display just fine. But, these errors also confuse some people who then decide to not fix a release, which is basically a lost contribution for Discogs. Therefore I think they need to be fixed at some point.
So I wanted to know: how many of these wrong entries actually exist in Discogs?
I adapted my scripts and processed the latest data dump. As it turns out there are a whopping 42,953 releases where the month is set to 00. They are distributed across the data as follows:
As expected, it is mostly the early releases where this problem occurs, but it also revealed something unexpected: the latest releases with a month value of 00 were from 2017, although no releases with this smell were added in the last 6 months. I checked the last 30 of them and most of them used an older release as a template, but not all of them.
This means that it seems that this rule ("0 is not an accepted month") only started to be a critical error in mid-2017. But that makes me wonder why there was a very sharp drop so early on.
Fixing this error would actually be very simple and could be done automatically by for example the DiscogsUpdateBot.
This notation is not universal. For example: where I live in Europe the default is DD-MM-YYYY and for reasons that I cannot understand in the US it is MM-DD-YYYY. I am sure the confusion is the other way around as well, but that's their fault (and in case you didn't get it: that is a joke). Suffice it to say: dates are hard.
My question was: how many releases have an impossible month (larger than 12) set? The answer: 417. They are distributed over the data as follows:
So what is striking is that here it is mostly newer releases that have this particular error. The most recent release I could find with this error is actually one of the last that is in the data set that I have, which includes all data until (not including) December 1 2017.
Of course, this error is very easy to detect and also prevent. By checking if the value of the month isn't 0, but also if it is not larger than 12 would be enough to prevent this error and inform the user that the value for the month is incorrect, just like when the value for the month is 0.
I'm hoping that a check will be in place soon. Until then I guess we will have to leave comments in the edit history and hope that people will fix it themselves.
Month equals 0
As it turns out there are quite a few releases in the data where the value of the month is no longer correct. Apparently in the past it was custom (or even mandatory) to have releases in full YYYY-MM-DD format, and if the month and date were not know the value 00 was inserted. This is no longer accepted and if you edit a release and the value of the month is 00 then the following error will be displayed: |
| Error message for wrong month |
This happens only for older releases that haven't been updated for years. It can be argued that this is mostly a cosmetic bug as the old dates with month values of 00 will display just fine. But, these errors also confuse some people who then decide to not fix a release, which is basically a lost contribution for Discogs. Therefore I think they need to be fixed at some point.
So I wanted to know: how many of these wrong entries actually exist in Discogs?
I adapted my scripts and processed the latest data dump. As it turns out there are a whopping 42,953 releases where the month is set to 00. They are distributed across the data as follows:
 |
| Distribution of releases with month = 00 in the Discogs database |
As expected, it is mostly the early releases where this problem occurs, but it also revealed something unexpected: the latest releases with a month value of 00 were from 2017, although no releases with this smell were added in the last 6 months. I checked the last 30 of them and most of them used an older release as a template, but not all of them.
This means that it seems that this rule ("0 is not an accepted month") only started to be a critical error in mid-2017. But that makes me wonder why there was a very sharp drop so early on.
Fixing this error would actually be very simple and could be done automatically by for example the DiscogsUpdateBot.
Month larger than 12
As a bonus I also looked at which entries have an impossible month. When editing a release in Discogs a few date formats are accepted: YYYY-MM-DD, YYYY-MM-00 or YYYY, as shown in the below screenshot: | |
| Input field for release dates in Discogs when adding or editing a release page |
This notation is not universal. For example: where I live in Europe the default is DD-MM-YYYY and for reasons that I cannot understand in the US it is MM-DD-YYYY. I am sure the confusion is the other way around as well, but that's their fault (and in case you didn't get it: that is a joke). Suffice it to say: dates are hard.
My question was: how many releases have an impossible month (larger than 12) set? The answer: 417. They are distributed over the data as follows:
 |
| Releases with an impossible value for the month of the release date |
So what is striking is that here it is mostly newer releases that have this particular error. The most recent release I could find with this error is actually one of the last that is in the data set that I have, which includes all data until (not including) December 1 2017.
Of course, this error is very easy to detect and also prevent. By checking if the value of the month isn't 0, but also if it is not larger than 12 would be enough to prevent this error and inform the user that the value for the month is incorrect, just like when the value for the month is 0.
I'm hoping that a check will be in place soon. Until then I guess we will have to leave comments in the edit history and hope that people will fix it themselves.
Comments
Post a Comment