Buglet in selecting a standardized date in FamilyTree
Test with Andras (LJPW-VV8).
The Date of Death field contains the string: "died at the age of 103." The standardized date is 0103.
This is obviously not correct, so I select "None of the above" from the drop-down list and saved the change.
When I open the Death field again, the standardized date is once again 0103. My change was not saved.
Answers
-
And now it has my name attached, but still no change: it refuses to save the unstandardized date.
Are we no longer meant to be able to enter conclusions without linking them to a standard?
This is aggravating: if there's anything in the box that the system "recognizes" as a date (even if it isn't), then it attaches that date as the standard, regardless of what the user tells it to do. I've succeeded in getting it to save without a standard by typing the age as "oneohthree". (Typing it as "one oh three" or "one hundred and three" doesn't help; the system thinks it recognizes those.)
Hah! The system doesn't speak Hungarian. You could write the age as "százhárom". (I've left it as "oneohthree".)
0 -
Am I missing something here? Surely the Date of Death field is not intended to include a note - about age at death, or anything else? I would leave this field blank, or you could enter an estimated year - around 1690 - based on the (estimated) year of Walsingham Andras' birth. Either way, surely the "died at age of 103" input belongs in the Reason This Information Is Correct box?
If there does appear to be a bug here, perhaps another example (including a more valid input) could be provided to help illustrate how there is a genuine problem here.
0 -
I agree with Paul that trying to put the age at death into the death date field is perhaps a non-ideal example, but I can understand the motivation: neither the reason box nor the collaboration tab will show in a tree view or in the exports that show up on other genealogy sites.
It is (or used to be) one of FS's advantages over other sites that its dual-entry system allows (allowed) for non-compliance. Sometimes, there just isn't an appropriate standard, or the information can be conveyed better without one. Or the red flag is desired, as a pointer for a problem in need of research.
0 -
I do not consider this information ephemeral, and at this time, the Date of Death field seems to be most appropriate. Fortunately, such statements are rare. Typically, this information comes from printed genealogies:
· Died at the age of [x]
· Died young
· Died in infancy
Aside from the name, this is almost always the only information available. There is insufficient information to either estimate or calculate a date.
Selecting the appropriate standardized date was not a problem before the new person details page was introduced.
0 -
We have not been able to leave a date non-standardized for many years. Even if it looks like you are not going to link a standard when you click save, one is always put on. This has nothing to do with the new pages. The program has worked this way for at least seven years or more. I agree with Paul that this is not a bug and that only a real date belongs in a date field and that the only place an explanation regarding the person's death is in the Reason Statement box with a reason such as "The book .... states he died at age 103."
However, I have no complaint with anyone making use of the flexibility of Family Tree and would say that if you want to enter that explanation in the date field you can, but since it ends in a number, the program will view that number as a date. There is just no way to specify that a number in the date field is not a date. Spelling out would work fine if you don't user proper English as Julia found:
Now you just have to accept the error flag on the record and that fact that the next user to come along will try to get rid of that flag by moving it comment to the reason statement section.
(I find it rather thorough of the programmers to have the routine recognize the use of words for numbers:
I assume this situation comes up only rarely when a source has no indication of when a person was born and no indication of then they died so you can not enter calculated dates. If you had any idea of the death year, then you could do something like this:
That keeps the important, accurate information front and center, will not encourage other users to "correct" it because it is not standardized, does make use of the ability to have dates with extended information, and falls in my rather broad definition of a date and what does belong in the date field which is consistent with my definition of a place.
0 -
Perhaps a slight amending of the wording might help. I just inputted "died at the age of 103 years old" and got this:
I think adding the extra "years" or "years old" does the trick. This doesn't carry over to Landscape / Tree view, but I suspect it would have appeared blank there even before the introduction of the new page.
1 -
I just tried @Paul W's tactic and it also worked for me - basically, it doesn't just standardise on a date, it also allows the standardisation of an age.
I entered a date of "14 years old" and it immediately ticked it as standardised to "14 years".
I never knew that... Was I missing something? Are there implications? (I am slightly suspicious about what it might think "14 years" actually means... Age? Duration? )
0 -
I still don't intend to make this type of input myself - primarily, because I think it is a misuse of the "Date of Death" field. (Personal view only.) However, I don't see it really necessary when the detail can be shown as a note in the "Reason This Information Is Correct" box, just below.
It took me a long time to realise the Death section of Vitals is the only one where a reason statement / note can be entered without having to add Date / Place data. On discovering this, I started to add facts like: "NOT the death discovered for a John Brown who died at Manchester in 1897", to make it clear this option had been considered (and rejected), but I still had not found any other close match for the death of "my" John Brown.
0 -
We've gotten well off into the weeds.
The primary issue is that the user was offered a value in an enumerated list and selected it. The selection was not saved. Either the selected value needs to be saved or the list entry needs to be removed.
A secondary issue is that there is no appropriate place to store data such as "died at the age of 103." GedcomX provides a solution, and I would like to start a new thread on this as an enhancement topic.
0 -
"None of the Above" has not been a valid choice for dates and has not been saved for many years but rather replaced with the default standard. I agree there should be some warning about this or the option should be removed.
With places you can choose "None of the Above" and it will be accepted and then put into the bucket for the Volunteer Project to replace with a linked standard as soon as possible.
I never would have thought of putting a person's age in the death date field. That is a very interesting feature and could come in handy in rare situations. It works, by the way, in any date field, even Birth.
1 -
Firstly, I really can't see what your objection is to having the date "properly" standardized merely by entering a word or two after "...103".
Secondly, there are plenty of places in order to record such data: in the reason statement field suggested, as a Custom Fact, or even in a Note in the Collaboration section.
1 -
Granted, I cannot come up with a good example for why you'd want to enter a number in a date field and not link it to any standard, but the fact is, you can't -- despite the system making it seem like you can.
The problem, as I see it, is not that you can't "unstandardize". The problem is the fact that it makes it look like you have "unstandardized" -- but it's lying through its teeth.
0 -
We appreciate you bringing this problem to our attention. The issue has been reported to the appropriate team, who will research the problem to find a fix. We will get back to you as soon as we have an answer. Thank you so much for your kindness and patience while this is being addressed.
0
