OK, but there should be a more general and sophisticated way for expressing multiple kinds of uncertain dates like:

• before - the uncertain date is before the date entered
• after - the uncertain date is after the date entered
• around - the uncertain date is around the date entered
• between - the uncertain date is between the dates entered

Vaclav, you want that, but I don't Fuzzy temporal databases are a very difficult problem. Please open a separate ticket if you want this

Václav: see MBS-2954 (not exactly what you're suggesting, but that ticket is for approximate dates whereas this one isn't)

Olivier, I just wanted to suggest that it could be a pity to implement a partial functionality instead of a more complete and useful one.

Example:
It is 2011 and I know that a former member M band B played on album from 2007 and not on the next album from 2009 and following ones.

• If I enter that M is not a member anymore without any date the DB does not convey much information and in five years it will give even less information.
• If I enter that M ended membership around 2008 then the DB is much more informative and it will stay informative in five years.

Regarding the difficulty of implementation:
Maybe I am naive but which operations we perform on dates in the database?

• compare and related like search and sort
• writing, reading and presentation

All these operations could be performed the same way as with ordinary dates except the presentation which requires displaying words like "around". There would be just a separate attribute indicating that the date is approximate. More complicated fuzzy date type is "between" but the essential type is "around" or "circa" as in MBS-2954. (Thank you nikki.)
More complicated "before", "after" and especially "between" are not so important to implement but the database scheme could be partially prepared for them by allowing additional values of the date uncertainty attribute.

Also the problem with century / decade etc. from MBS-1385 could be solved by additional attribute "order of magnitude" so in combination with "around" we could create dates like:
X was composed around 1780s
or for example for a traditional song:
Y was composed around 15th century

So my point is why to implement a partial functionality when a much better alternative exists?
Maybe both functions could coexist but I see many use cases for approximate dates but none for unknown end dates which could not be specified by approximate dates combined with "order of magnitude".

Setting due date based on when this task was moved to 12mo bucket.

In what was pretty much a duplicate of this, navap proposed to "Add 'dead/disbanded' column to artist table". That could work - we could display "unknown" in the UI, as in "Member: Foo Bar (1954 - unknown)" and "Dead: unknown"

The point of this is being able to say that a person is dead / a band has disbanded, or that a person is no longer a member of a band, even if the exact dates are not known.

We could add a checkbox to the "Add/Edit artist" and "Add/Edit (member of) relationship" that says, respectively, "This (person is dead)/(band has split), but I don't have a date" and "This artist is no longer a member, but I don't have an end date" (wording can definitely be improved). The same structure used for "member of" could be used for "married", although that's clearly less important for MB.

All the artists with an entered end date should be marked as "dead/disbanded" automatically. All member relationships with an entered end date should be marked as such automatically (in the way we decide to mark it).

This ticket is under consideration for the May 15h schema change release. However, it is under specified at this point in time. In order to keep this ticket in consideration for the release, please do the following:

• Specify exactly what the user interface changes will be. Mock ups would be great. Due date: April 2
• Specify exactly what the database changes will be. We will need to have an exact database table change proposal. Exactly which columns will be added/removed/modified and what new tables will be created. If you cannot specify the changes to be done, chase down a developer to specify them for you. Due date: March 26

Database changes:
Add a boolean "finished" column to the link table
Add a boolean "finished" column to the artist table
Add a boolean "finished" column to the label table

I think simply adding that boolean is not enough. For example, what happens with end dates? If we have an end date, does that imply finished should also be true? If so, we need a trigger that helps us ensure this invariant - when the end date changes from empty to non-empty, then finished should be true. But also, what happens the other way? If we go from a non-empty end date to an empty one, should finished change?

If we have an end date, finished should be true, yes (and in the UI, it would block the "finished" checkbox as marked). If the editor removes the end date, I guess we should by default unblock + unmark the checkbox in the UI, and let the editor decide whether to submit it like that (thus unsetting it) or mark it again (thus making no changes in "finished"). Now, how to exactly put this into tables, I don't know.

After discussing this with Nicolás on IRC, we are in agreement that we need a way to ensure the following:

• If there is a non-empty begin date, but the finished boolean is true

As for leaving this state, (going from non-empty to empty), there's nothing to do at the database level but the user interface should suggest unchecking the finished boolean.

This ticket is in danger of being rejected from the upcoming schema change release. Please provide UI mock-ups today.

I think the changes were pretty obvious as per the comments, but well, there, mockups attached.

Isn't something like « this person has deceased » less harsh than « this person is dead » ?

The UI discussions so far only discuss how the editing looks, but does not show how the data should be displayed later.

Also, this will have implications in the web service, which shows relationships - how should this data be presented in the web service?

The most normal way I've seen this kind of thing displayed is with ???? in the end date, implying there is one but it is unknown. I'd be happy displaying that (in the "dissolved", "dead", and relationship dates sections).

For the web service, it doesn't really change existing stuff, only adds new stuff, doesn't it? So I would expect just adding it is enough.