Which date is correct on individual recordings? (correct wording vs. date range)

When adding relationships to recordings and releases we can use an exact date or a range. If the exact date is not mentioned for the recordings but the release was recorded in a range of dates, we can not display, that individual recordings are not created over a period of dates but in between or on some(one of these dates.
normally, if i encounter a range, i do it like this:

on release level i like to add the whole date: recorded at: Studio Peter Karl in Brooklyn, New York, New York, United States (from 2016-07-21 until 2016-07-22)
on individual recordings i add the next best known information: recorded at: Studio Peter Karl in Brooklyn, New York, New York, United States (in 2016-07)

my problem here is, that the wording from 2016-07-21 until 2016-07-22 is logically incorrect. the individual recordings have not been recorded in most of the cases over a period of days, but on one day. since we cannot know the exact date by the given information, i like to leave it out.

here is the start of a couple of recording edits and a little discussion: Edit #101119774 - MusicBrainz

“better to have a range of 2 days than have a range of 31 days, which is what leaving just the month would mean.”
is there a rule for this? even if the wording is false? i think we have to differ between release dates and recording dates.

there might be a solution to the problem which i encounter in some other databases. Sometimes you can specify, that the date is not the exact date but it’s “about” these dates. now the reader (may it be human or machine) has a hint, that it might be either/or, in between sometime, or on multiple dates in the given period.

what do you think?


Open ticket regarding approximate dates: [MBS-2954] Add circa checkbox to field dates - MetaBrainz JIRA

I get where you’re coming from, but personally I’m okay with (a small amount of) over-precision. I think date ranges can be understood to be somewhat flexible; if a release was recorded “March 4 - 17” it doesn’t necessarily mean they recorded every single day during that time.

Maybe a simple phrasing change of “Between X and Y” rather than “From X to Y” would help?


I also typically use the more specific date. for example:

that said, it’s probably a good idea to leave a comment on the ticket @highstrung linked above and leave an annotation on the release and/or the recordings (preferably both) explaining the situation

I would stick to the range of two days as this is more accurate than a range of the whole month.

1 Like

How is the wording false? It was recorded in the period from X to Y. I guess your issue is that it doesn’t specify the “in the period” precisely? That’s still true of any date ranges given in any release though: if a release said “recorded June 11-13 2020 at Some Studio”, some songs were still probably recorded in June 11, some 12, some 13, and the range is probably not strictly true for most of them. It’s just the best we have.


I mean english is not my mother tongue but:

“From X until Z” means a specific period of time, right? It means that something happened on X, maybe Y and Z
“In between X and Z” means a non specific period of time. It is a range where something happened.

i think we can do better and be more precise!

@highstrung thank you and @jesus2099 for the Ticket!

i disagree, it is not more accurate.

More precise is naming two days instead of 30days. A whole month is many levels of less precise.

And remember - it is only the GUI that says “from X to Y”. The database just holds a start and end date to cover a time period. Maybe you are better to read it as “recorded between X and Y”, would that translate better for you? But please don’t use a literal misreading of the GUI to delete accurate data.

For anyone else reading this thread here are the recording edits

it is not precise, because there are false implications. the grammatic base does not enable to reflect a vague recording date or range yet.

researchers do not care about our knowledge of differences between GUI and what it means. this database should be for everyone and information retrieval should be clear and unambiguous.

edit: however, a ticket is here, it only needs to be refined and implemented. to me, this sounds like a good solution.
sometimes i do not have a lot of fun here. i often encounter anti-progressive thinking and argumenting and sticking to systems without looking at the flaws. i would love to see more openness here. the only argument i read to the current state of art is that it would be “more precise” but argumenters totally ignore the fact, that the english language is ambigous here.

I totally agree with you the English language is ambiguous here. It is the language of the web page presenting the dates that could be adjusted instead of loosing the accurate data.

If the guidelines were updated to be clearer as to what the dates represent then that would be a better outcome than loosing accurate researched data due to how they are represented on the page.

(And sorry if I am coming over as argumentative. I am just rubbish at writing a post. Nothing personal is meant)

Sorry, but there’s nothing progressive in saying “there are slight imperfections in what we can do, let’s make it entirely worse instead” :slight_smile: (the suggestion to just use the month or nothing at all).

The “circa” suggestion makes some sense, but that wording is also equally ambiguous, for what it’s worth: “circa” 21-22 could also be 20 or 23. In fact, the usual usage of “circa” is for things like “born circa 1210” or whatnot, where it could be entire years off.

For something like this to actually be useful, I think you would need a lot more options than that.

“in range”
“either-or” (with more than two options)

The last of these is the most interesting IMO, because that’s the one case where our current setup fails the most: we can either add a range of which we know some parts don’t apply or separate dates of which we know probably only one applies. Sadly, it’s also the most complicated to implement by far since you’d need a way to connect the options, which is not supported by the way relationships are built (and more than two-point relationships would involve a large rewriting of the whole database).

If you just have “about these dates”, you basically have no good info about whether we know it is inside those dates, whether we think it’s somewhat close to those dates… it’s a much bigger source of ambiguity in general.


it would be better if data would be accurate. yes a month is more accurate than mentioning a date where the recording was definetely not recorded. no one wants to make it worse.
with progressive i mean pointing out something that is not correct. however there’s always someone who says “cannot be done”, “too hard to change”, “you better learn the rules” or “we did it like that all the time and there’s no need to change”. in my experience this is a reflex mechanism which occurs if something would mean work with only little benefit in the end.

i mean this is not a reviewed ticket here, i was just writing some suggestions from the top of my head.

so why not make a checkbox with about/circa/in range, that can be added additionally to a date. like adding “additional” or “guest” to an instrument/artist relationship? nothing would change for you, but you could tell as a reader, that the data is not precise about the recording date.