Date Standardization

LegacyUser

Adrian Clift said: Automatically standardize dates. Users -- or at least I do --presently spend a great deal of time manually forcing date standardization. Suggest automating this process. If an SSDI or marriage record comes in as 5 Aug 1921 and your index key or other preference is for the month to be spelled out, just import it that way. :-)

LegacyUser

Tom Huber said: While the suggestion has merit, any automated process runs the risk of mangling a perfectly good entry.

Right now, many entries were imported from some other system and are far from being intuitive to a coded process.

I don't recommend it since computer intelligence is still a matter of science fiction and not reality. Computer programming can mimic intelligence, but it lacks the nuances of intuition, which is something that we humans possess.

LegacyUser

Tom Huber said: By the way, I'm not against the idea, but my experience with any automated process and the massive tree has not been good.

LegacyUser

Jordi Kloosterboer said: You can have an original date and the "fixed" date, though. They do the same with places sometimes.

LegacyUser

Adrian Clift said: Well, someone screwed up an entire census index on here by plugging "Grainger" for "Giles" counties in Tennessee, so I get the concern. OTH, if Family Search is going to flag "non-standard" entries with red exclamation points because it wants DD-MonthSpelledOut-YYYY in a field designated as "DATE" it is an onerous request for serious researchers trying to contribute to the general good.

August 8, 1921 is exactly the same date as 8 Aug 1921. Why import 8 Aug 1921 from a valid data source and then insist it be changed to 8 August 1921 to rid the screen of red exclamation points? :-)

LegacyUser

Jeff Wiseman said: Adrian,

I think that you might be assuming something about the dual date and dual location mechanisms that is not true.

8 Aug 1921 can be entered into the date display value in a way that not red "!" appears. For example, if you put that date in that format into the Edit Birth field, the software suggests a standardized event date:



If you accept that suggested assignment of the Standardized event format, you will get the following displayed on the main Details page:



However, if you go back, re-edit the birth date, and REMOVE the standardized Event date format that was attached to your date display value of 8 Aug 1921, as shown here:



You will produce a display date that has no Standardized Event Date format assigned to it:



The place names works the same way. There are up to TWO Dates stored in the system for every Date vital. There is the Date text that is displayed in the vital, and then behind the scenes, there is a "Standardized Event Date" that is assigned to that birth date. The fact that your display date has a "behind the scenes" Standardized Event date" assigned to it makes that display date "Standardized" (i.e., it will have no red "!" next to it showing that it is not standardized).

You do NOT necessarily have to have a "Standardized Event Date" in the display date field in order for it to be "Standardized" (i.e., no red "!"). However, if there is no "Standardized Event Date" ASSOCIATED with the value that you have in the Display value field, That display value will be considered non-standardized, and you'll get the red "!".

I apologize if this description is a bit cryptic as I've tried to use FS's terminology here. FS uses the terms "Standard" and "Standardized" in a totally inconsistent manner on the website that makes their meanings totally ambiguous. However, I personally feel that the dual location and dual date type fields is an excellent implementation with great capabilities (once a person figures out what is really going on).

Oh, and BTW, if you attempt to actually remove the Standardized Date event as shown in the last 2 images above, you will not be able to save it. Whenever you do the save, it is automatically throwing away what you just attempted to save and replacing it with the previous standardized date event from the pulldown list. This appears to be a bug that FS needs to address. See:
https://getsatisfaction.com/familysea...

LegacyUser

Tom Huber said: See Jeff's response below. The red exclamation point does not appear because of any entry in the user-entered field. What the exclamation point appears for is a missing or mangled "standardized" entry. Correcting only the standard fixes the problem and leaves the user-entered date alone.

LegacyUser

Adrian Clift said: Apparently I am a poor communicator. Please understand that I understand how to get the system to plug "acceptable" data. In fact I do that ALL THE TIME for all sorts of other fields as well. Finding cemetery names that match is particularly adventuresome.

LegacyUser

Adrian Clift said: Have you linked an SSDI record lately? Have you seen how much EXISTING data is "non-standard?" Never mind. Thanks for all your help. :-)

LegacyUser

Jeff Wiseman said: Please don't leave just yet :-)

Are you saying that when you are copying over dates while using the source linker, the dates do copy over (e.g.. 8 Aug 1921), but the system puts up a red "!" indicating that they have not been standardized?

If that is what is happening, then something appears to be broken. My understanding was that whenever a date is brought into the system, the system automatically tries to assign a "standardized event date" to it. The system is NOT supposed to change the incoming date (i.e., the date display value of 8 Aug 1921). Rather it is supposed to simply find a Standardized event date that is it's closest guess to what is being entered and then assign that standard to it.

Again, if this is what is happening, something appears to be wrong. Since I just discovered another problem with the standard assignments for dates in another topic, it would not surprise me that something else here is broken.

LegacyUser

ATP said: Adrian Clift,

Your experience with the indexing showing up Grainger County, Tennessee for Giles County is the same encounter I frequently have with Montgomery County, Tennessee the county I do extensive work in on my Scotch-Irish ancestors. If I do any more research in the next couple of hours, there's a good chance Grainger County is going to show up. Sometimes, Giles County is in the mix! : )

Haven't had time to investigate why this particular indexing error since I only use the index to get to the real record, and last night when I tried to change the incorrectly indexed Grainger County for some reason it would not accept the change. Not fretting too much about it, since, it probably was a temporary glitch.

And, yes, finding matching cemetery names is quite an adventure, especially in the country areas where names of cemeteries still continually evolve!

LegacyUser

Gordon Collett said: Just to further clarify, without, I hope, being annoyingly repetitive, there is no "preference is for the month to be spelled out," as far as the Family Tree program goes and no need to fix any date format as long as the date does not have a red exclamation point. Don't waste your time changing 30 Aug 1930 to 30 August 1930 if you have better things to do. Don't sacrifice research time in the name of a changeable concept of nice appearance for data.

As far as Family Tree goes, the program is perfectly happy if you enter any of the following:

23 AUG 1930
Feb. 23, 1905
14 Mai 1875 (this is not a typo, it is German)
Tuesday, June 2, 1874
1945-10-5 (this ISO format is not ambiguous.)
3/15/1845 (only discouraged because it can be ambiguous but still allowed)

and probably many others. All program routines work just fine with these as long as the correct explanation of what date you really mean, i.e. the "standardized version" is attached. The dates are not forcibly made to conform to that standardized version in case the particular user entering the date in Family Tree wants or needs to use a different format.

LegacyUser

Adrian Clift said: I do not know what is going on behind the scenes, and I suspect you don't either. I happen to be a retired database application developer, though, and my GUESS would be that the database administrators have three objectives: 1)use an index token for the full data field to speed up search (important in search speed), 2)ensure that locations are easily expressed as GPS coordinates so that users can view maps of data (because we can now do that), and 3)greatly improve the aesthetics when viewing a person record.

I was simply making a suggestion to support them and all users.

I do appreciate everybody's willingness to help me use this platform, but I have viewed and/or edited literally thousands of records in the past few weeks, and feel fairly comfortable getting around here.

I DO have better things to do, but it is not to be here explaining myself over and over. (In fact, I would rather be manually standardizing data rather than commenting repeatedly here.) :-)

Everyone have a good day, and HAPPY HUNTING! I will not be responding further to this thread.

LegacyUser

Gordon Collett said: This is a very helpful and vocal community here so you may still get more comments. If you don't want to be bothered by them, go to the top of this posting and click the (unfollow) link to stop getting e-mails from this thread.

LegacyUser

Jeff Wiseman said:

I would rather be manually standardizing data...

I just hope that what you mean by that is NOT going through and replacing display date or location values with the exact standard values as provided in the standard places database. There are a lot of people that have been incorrectly told to do this (i.e., make sure the "map pin" icon is showing). I've had to stop many people from doing this as they were walking through the tree destroying a lot of useful details in the vitals.

Many of the date/location display values that I have researched and entered in the system are FAR MORE ACCURATE and useful than just the standard value I've associated with it. When those values (which are already "Standardized" using FS's terminology) are replaced with exact values from the place standards database, useful information is lost. Others have had this same experience. Understanding how the Dual name system works is NOT intuitive.

People not truly understanding how this works consistently results in destroyed information in the system. The fear of that happening and forcing us to have to go in again and repair that kind of damage is one of the reasons many folks here become rather passionate about this subject.

No need to respond. Please just try to understand why so many folks here are concerned that patrons understand the dual name system and DON'T go through undoing useful work that has been put in place.

LegacyUser

Tom Huber said: Yes, there have been a number of threads that have had users (and I agree with this) suggest that the "map" pin not be shown on the profile and therefore, there is no reason to make the user-entered data and the standard place agree.

LegacyUser

Jeff Wiseman said: Tom, because so many people don't understand what it means and myths are created about it, yea...I could see removing the Pin icon for that reason.

However, I like it being there because it provides information to ME:

• Red "!" means no standard has been assigned so you really don't know where in the world that place is!

• Pin icon means that the displayed value has been taken directly from the standard places database

• No pin icon and no red "!" means a standard has been associated with the display name and either:

• The Display name and the standard place name associated with it have NOTHING to do with each other (i.e., a mistake), or

• The Display name contains MORE DETAILED INFORMATION in it than the standard name associated with it!

Since having both the missing pin and the missing "!" at the same time identifies the one circumstance where you MIGHT have an incorrect standard value assigned, it is a flag to me to always check the standard that has been associated with the display value.

LegacyUser

Jordi Kloosterboer said: I almost always replace 14 Jan 2020 to 14 January 2020. Usually, the date fields I deal with do not include more raw information than what the standardization does. I like the look of the month fully spelled out. However, if it has a time and a date like 13:35 14 Jan 2020, I would probably change it to 1:35 PM 14 January 2020 (or just leave it) and that would have a standard date of 14 January 2020. So that would show 1:35 PM 14 January 2020, but still only have the date as the standard since FamilySearch does not standardize times.