Double dates for Jan/Mar of appropriate years

LegacyUser

Susan Plass said: It may not be trivial to code, but it would sure be nice (and more accurate!) to recognize and accept double dates for the appropriate time period.

LegacyUser

Gordon Collett said: How do you try to enter the dates now? How do they look when you are finished? What would you like them to look like? Do you have a specific example?

LegacyUser

Susan Plass said: Sure: Eunice Lamb LX4H-L6B. She died March 1734/5 -- the sorting year would be 1735, but it was still 1734 then. That is, the next month was April 1735. So it is usually, even in records of the time (Groton Town Records), written as 1734/5. And in her Person view it shows that, but in the Family Member list it shows only Deceased. And there's no way to use a standard format for it.

What I'd like to see is the date March 1734/5 accepted as a standard format, with FamilyTree understanding the sort order so in particular births show up in the right order.

Blue sky: If I tried to double date outside of the accepted range (eg, after 1752), I'd be warned it was incorrect.

LegacyUser

Gordon Collett said: This is one of the few situations I have seen that some sort of "standard" is not offered so that there is a proper sorting date.

Here is something a bit strange:
1734/5
1734/35
do not offer any standard

1734/1735
offers 2 July 1734 and 2 July 1735 as options

March 1734/5
March 1734/35
March 1734/1735
do not offer any standard

12 March 1734/5
12 March 1734/35
12 March 1734/1735
all offer 12 March 1735 as the standard
(You are aware that in this case you would just click outside the text box, not on the 12 March 1735, to keep what you typed as 12 March 1734/5 but set the green box to 12 March 1735 - which is merely the date that is used for sorting and to get the four digit year to display when just that is used, right? No one should be seeing that green box unless actively editing the data.)

So currently the programing can handle double dating if the full date is entered (but not a partial date) in that children would sort properly in birth order and a reasonably appropriate display is used when just the year is shown.

Maybe one of the programmers will see this and take up the challenge of getting it to work when just the year or just the month and year are entered.

LegacyUser

Susan Plass said: I hadn't figured out the double date worked for a complete date -- I have others with complete dates that I'll try this out on. Thanks very much for the tip!

LegacyUser

Paul said: I agree with Gordon. I only discovered the problem with entering the double date just a few days ago.

There doesn't seem any reason why March 1734/35 (etc.) can't appear with March 1735 as standard - after all, in this example, all days in March from 1 - 31 have the same standard year of 1735.

The programmers have overcome far greater problems in this area, so hopefully can sort out something with this one!

LegacyUser

RealMac said: While "double dates" were used in England and its territories, that is only a small part of the story. The Gregorian calendar reforms, as well as the decision to begin the year on January 1 rather than March 25, were adopted at very different times in different countries, and not always uniformly even within a country. Consequently, it is necessary to be very, very careful when formulating standards. At one point, Family Tree Maker had two settings for dates, such that either no double dates could be entered at all, or else everything before 1752 and falling between January 1 and March 24 was displayed as a double date, regardless of the geographical location associated with the date, or whether you wanted that date shown that way or not. What does that program do now? I have no idea, I stopped using it when I discovered that "feature"!

Even before the Gregorian reforms, it is not unusual to find multiple calendars in use even in one place. In medieval documents, it is routine to find some dates reckoned from the Annunciation (March 25), and others from the Nativity of the Lord (i.e., Christmas), or, apparently, January 1. In many cases there is no way go be sure what was intended, so we have to get in the habit of quoting dates exactly as they were written, and interpreting them with a very large grain of salt.

Even in places where double dates were supposed to be in use, it is not necessarily true that everybody followed the rules. The researcher has to be aware of the different systems in use and evaluate the evidence carefully. In a baptismal register, where the entries are usually in chronological order, we can usually work out which system was being used. In isolated documents, it can be much more difficult to prove the year.

One approach to the difficulties of the various dates on which the year may have begun in the past is to convert everything to the so-called "historical year", beginning on January 1. If this can be done correctly, then all the events of the past can be sorted in the correct order. However, if this is done, we may lose sight of any ambiguities in the original dates. I would prefer to see the dates displayed in something like their original form (1734/1735, for example), while sorting on an internal "historical date" value that is not displayed. Also, we certainly don't want to impute double dating where the original date was reckoned from January 1. The solution to these concerns would seem to be (1) allow the user to enter a double date if appropriate; (2) convert any such user-entered double dates to a standard double date format, such as 1734/1735, for display purposes; and (3) store the date internally in "historical date" format (reckoned from January 1) for purposes of sorting only. Any dates not entered by the user in double date format are to be left alone, not turned into double dates!

LegacyUser

Paul said: I think we are all actually in agreement here, RealMac. Certainly, all I am suggesting is that is should be possible to enter / retain (say) 1734/35, 1734/5 or 1734/1735 in the box, but for the standard to show (in green) as 1735.

I agree with your points about the problems connected to various dating systems but don't think that is really relevant to the simple point being made by the original post: if one enters 1734/35 in the box a "No Standard Available" message appears below. (In other examples, an incorrect "Standard" date appears: for example, try entering 1604/05.)

LegacyUser

Gordon Collett said:

RealMac wrote: I would prefer to see the dates displayed in something like their original form (1734/1735, for example), while sorting on an internal "historical date" value that is not displayed. Also, we certainly don't want to impute double dating where the original date was reckoned from January 1. The solution to these concerns would seem to be (1) allow the user to enter a double date if appropriate; ... (3) store the date internally in "historical date" format (reckoned from January 1) for purposes of sorting only.

Actually, that is exactly how Family Tree operates now:



The only hiccup is that the list of sort dates is not complete. The "standard" list should include every possible interpretation of any date anyone could possibly type in. No one person could sit at a desk and think of all of them so I certainly don't fault the programmers for missing a few.

Typing 1734/35 should bring up 1734 and 1735
Typing 1604/05 should bring up 1604, 1605, and May 1604.

You can play around with dates and see what standards get triggered at:
https://familysearch.org/stdfinder/Pl... (click on the Date tab)

You can also e-mail that team with suggestions. Just click the feedback link on that site. You might want to put together an e-mail to them, Susan, explaining exactly what you would like to have happen with your dates.

LegacyUser

Susan Plass said: Gordon, I had no idea FamilyTree was saving both what I type and a standard form of the date. Thanks for the explanation. Is there somewhere I should have read to be better informed about how data is stored? I only found out it didn't work the way I'd want it to by experimenting with Eunice. (That date, by the way, is exactly as written in the original town record -- with the double date.)

I also have no clue how to email the developers. I had the impression that they were carefully protected and that the feedback mechanism was how to convey a wished-for change.

LegacyUser

Gordon Collett said: Click on the link in my last post to go to the page where you can send feedback directly to the people in charge of standards.



My theory about how dates are saved has been developed from many comments from the Family Search employees that answer questions on this board and personal experimentation. I haven't seen it in print the way I explain it and I hope I'm not leading people astray. I have seen, however, a lot of people very upset because they think the only choice for the white box of text is what is in the green box of text. So I've kind of taken on a personal crusade to show that is just not the case. Place names work the same way. You can enter the place name as completely and as accurately as you want it to be and as long as that triggers a proper geographic choice for the green box, the program is happy.

I didn't mention previously in this topic, but just for completeness will, that there are three ways to close the speed entry drop down menu and preserve what you type in:
1) Click anywhere outside the text entry box.
2) Press the tab key.
3) Select "None of the above."

LegacyUser

RealMac said: I hope all of the features described here will work together, and that the user will find some guidance when any of these situations arise! Many genealogists are completely mystified the first time they run into dates that don't follow the modern standard.

Gordon's example, Dominca 6 post Trinitas 1784, isn't an example of a double date, but it does introduce other difficulties concerning the dates that we find in real documents. Even for this example, where you might think that a computer should automatically look up the date of Easter and compute the date of the 6th Sunday after Trinity, the burden is on the genealogist to review the original records, because one can sometimes find cases where someone was either not using the "standard" date for Easter, or else made an error of some kind in reckoning the moveable feasts that depend on the date of Easter. There are so many possible complications, I wonder if there is yet a comprehensive reference somewhere on FamilySearch on "Date Problems for Genealogists"?

Briggs, Suzanna Reed

I found that should a child be born in say June of 1735 and then the death says the child died in February 1735, it causes all sorts of problems in the system. The indexing guidelines were set up to deal with this issue. I agree, the double date is the most accurate, or at least let us be allowed to edit the double date so that no child will die before they are born!!!

Paul W

Suzanna

This is a very old topic, dating from August 2014. If your issue applies specifically to the indexing of such records, it is probably best to raise a new topic in the Indexing section of "Ideas".