I hope this is the correct place to report this bug. I don’t do digital uploading, but the script needs to be fixed to avoid obvious errors in the data.
https://musicbrainz.org/edit/74340145
Obviously that Digital Album was not released in 1981, but there is the release date on Apple’s website. This then got imported as 1981 when the digital release is clearly much later.
Deezer and Spotify have the more logical 2005 dates.
With re-releases like this, there’s usually 2 dates provided by Apple/Deezer/Spotify/etc, the original release date and the re-release date. A-tisket has an option to change the release date if you know it’s wrong, and it’ll say the date has been changed in the edit note when submitting.
The “option” is no good if it is uploading bad data like that. This one is obvious due to the huge gap, but other times it will be more subtle. Can this script not use a bit of logic and pick the NEWEST date as this will usually be the correct one for the digital? Or at least put a much more obvious warning up for the uploader when there is a difference?
Or plain ignore Apple now they are giving data not connected to the Digital Version? With THREE sources like that script has it should be able to compare and drop the one that is different.
People trust scripts like this too much and often don’t even look at the data. Clearly if this uploader had looked they should have known that 1981 was all kinds of wrong and not only did none of these companies exist, we didn’t even have digital CDs at that point 
eh, people have put in the wrong year for cd’s for aages.
on the flip hand, i do believe that MB has a warning for early digital and early cd, but I think you can ignore sometimes,I suggest pebcak here.
Highly unlikely at this point (sorry) but I’ll keep it in mind. How did you find this endpoint?
That is not an excuse to continue the bug into the Digital world 
And I thought there was now a block to stop dates like 1981 for CDs?
This surely is a bug in the uploading code. When there are three dates available, why can the routine not discard the clearly bogus one? Yes it is PEBCAK, but the users mistakenly trust this digital script. they have to actively type in a bad CD date, whereas they are more likely to trust a script as correct.
If Apple sends the original release date for old albums rather then the digital date it does make their dates a bit useless… at least any digital Apple dates pre-2003 can be safely discarded (If we’re being generous and look at when the iTunes store started), otherwise pre-2015 (Apple Music start).
In the … menu on each track on an album page of open.spotify.com there’s a “Show credits” option. Inspecting the network requests via your browser’s dev tools when clicking it shows the requests, from which you can find the endpoint. AFAICT it’s not documented anywhere, and since it says “experimental” in the path, it’s probably internal and will may/will change in the future.
my point here is that it’s whoever imported the release’s fault. not the scripts/tools fault
sure, we can improve the script and make it better/easier to not do wrong, but the onus is always on the editor to enter correct data, not on the tool they use (unless the tool is malfunctioning or introduces errors) you could argue that’s happening here, but since it is the user who is choosing the “wrong” date, that isn’t so, imho.
Myself I haven’t used this tool because i don’t understand how it works (and also I don’t usually work with spotify/itunes etc) precisely because I don’t want to do introduce any errors (and also because I have yet to need it, but that’s a different thing. 😸)
This is especially true since MB has now warnings to help prevent these kinds of things. the user is the one to blame for failing to use the correct date, failing to heed warnings in mb and probably just doing thinks quickly without noticing errors. it can happen and it’s easily fixable.
it is a PEBCAK, not a code issue.
For what it’s worth, we don’t have warnings for early dates for digital because we don’t know what’s the earliest legit digital release. Probably something amateurish in the early networks of the 70s or 80s 
fair enough :D
but maybe we can set a date of “probably only special cases before this date” warning?
like "the date is a very early date for digital, most releases are probably after $YEAR -ish, are you sure this is the right date?
since in the wast majority of cases, a 1970 digital release will be wrong.
I also don’t use this tool or do much digital editing, but the tool must help in flagging up this clearly bad data. The users are not checking the countries, so why are they going to check the date?
I agree it is PEBCAK - but this is no excuse for the tool to create bad data when it has three sources it is bring in dates from. If iTunes is now doing data that is not compliant to MB guidelines, then it should be flagged up as needing to be checked.
If three sources have different dates they that needs to be in big flashing lights are part of the import to be checked by the user.
@CatQuest - I guess you don’t work with many normal users if you think everyone is checking the data this script it producing. Like you I would like to think they are, but clearly they are not. 
In this example the date was 1981 - way before most of these companies existed and certainly before anything digital was being sold. If the user failed to see a 1981 error, then they won’t notice errors in dates in the 21st Century.
Yeah, that’s fine and MB is correct with that. This is not a MB issue. This is a script issue. This is a script adding something from 1981 was supplied by three stores that did not exist at that time. This is why it should be a script issue to fix.
For the script writer, would it be that hard to add a line that checks if (Deezer date) == (Spotify date) == (iTunes date) and if there is a big difference to discard the date with the largest variation from the average?
Nobody’s saying that the tool is at fault, but the tool has many many excellent features to make editing life easier, far above and beyond what I would have expected. So it doesn’t feel unreasonable to ask/advocate for something like this 
… this is exactly my *point* auuugh…
look this is pointless. I’ve said my bit.
aerozol: no actually that’s exactly what’s being said, that the tool is at fault.
my gripe here wasn’t that improvements were asked for or suggested, but insultingly demanded.
as an aside; just today I had to go and correct something I had imported using a Tool, the bandcamp importer.
I neglected to check script/language and had to go back and fix it.
it’s that simple. human error. tools are tools. not AI.
SURELY they can be improved, and should be.
but these are improvements, not " the tool create(ing) bad data "
EOM. I’ve said my bit, I won’t reply further.
I am very sorry if you think that was an insult. It was not supposed to be in any form an insult to anyone in any way. You have misunderstood my meaning here. Sometimes I just care a bit too much about the quality of the data.
Again, I am very sorry to anyone I may have upset by these comments. That was NEVER the aim.
I just noticed today that not only do iTunes album URLs automatically redirect to the Apple Music web player, iTunes artist URLs do as well. @atj, I highly suggest you update your instance of a-tisket to generate the new URL format for both artists and releases.
For those who are concerned about indicating that a release is available in the iTunes Store in light of this change, I’ve introduced this:
Can’t get past a 500 page error with this release:
https://atisket.pulsewidth.org.uk/?preferred_countries=US&spf_id=0Fn3ClzEUGH4ak4JB2Stq8&preferred_vendor=spf
When trying to submit an itunes id there’s no http error but I get no output.
Example: https://etc.marlonob.info/atisket/?preferred_countries=us&itu_id=579919658&preferred_vendor=itu