Reading the code (gramps/gen/lib/date.py) reveals that date quality if bitwise encoded.
This means that a date may receive several quality flags: NONE, ESTIMATED, CALCULATED and even a potential INTERPRETED (presently commented out).
However, UI allows only selection of one flag through a drop-down menu. Is this a shortcoming in development?
Also, if nothing is done while entering a date, is QUAL_NONE automatically added to the date? No flag at all should be equivalent to NONE. Is it really necessary to introduce QUAL_NONE since quality is not an enumeration?
IMHO it makes sense to have both ESTIMATED and CALCULATED for a date, e.g. it can be deduced from another date which is itself estimated. Therefore, the ESTIMATED flag should be transferred to the computed date to clearly show it is uncertain.
Should the UI be changed? In this case, how could this be addressed in a generic way so that various flag collections (differing in number and labels) could be managed automatically? A list of t-uples like (English flag name, translated name) where the encoding bit is deduced from position in list?
I thought that was a GEDCOM constraint, that an approximated date could be “about” or “calculated” or “estimated” but only one of those? Not to say that our hands have to be tied by the GEDCOM standard, but if we allow multiple values then we need a rule for which one gets exported.
If anyone begins tweaking the Date Selection dialog, it would be nice to consolidate access to all the date features & fix a few incompatibilities. It will probably need some adjustments anyway since 5.2 adds support for quarters/seasons. (Will ranges/spans of seasons/quarters be permitted? i.e., “between spring 1745 and fall 1745” or “from 1st quarter 1865 to 3rd quarter 1867”)
It would be nice to have a expanding Pop-up menu to encourage access to date related features: Dates tab of Preferences, date Calculator gramplet, Calculate Estimated Dates tool, maybe even the Calendar Tools Holidays
BTW, it is a bit odd that the Date Calculator outputs a range format that can’t be parsed by the Date fields validation.
As a basic layout, the date selector dialog could be a bit cleaner. It doesn’t make sense that there is extra space between the month & year of both the “Date” and “Second Date”. That space should be move to delineate between those 2 dates. (Which might be relabeled “Beginning Date” & “Ending Date”.)
Eventually, it would also to have a parser input (like the Latitude/Longitude parser) too so that you don’t have to cancel out of the dialog to get to that feature, then re-invoke the dialog.
