* Invalid double dates?

[Mark1834]

A couple of comments on FH double dates:

FH accepts any date as a double date, providing that the years are separated by one. For example, "23 Sep 1745/46" is accepted without comment, even though there is no year confusion in September. It also accepts "2 Feb 1550/51", despite the Gregorian calendar not being introduced until 1583. This may be a relatively rare example of RM having more rigorous validation than FH, as it only accepts double dates between 1 Jan and 24 Mar for years later than 1583. Shouldn't FH do the same?

FH also accepts double dates with just a year, such as "1743/44" (as does RM). To me, if a year is given on its own, it is implicitly by the calendar in use at the time, but entering "1743/44" forces FH to treat it as a Gregorian date. But what does it actually mean precisely in terms of the date range defined?

[tatewise]

See the FH Help page The Gregorian Calendar.
That explains that the Julian to Gregorian changeover date may be many years between 1582 and 1927.
Tools > Preferences > General tab allows Changeover to Gregorian Calendar: 1582 or 1752 (the default).
The GEDCOM specification is very vague:

YEAR_GREG := {Size=3:7}
[ <NUMBER> | <NUMBER>/<DIGIT><DIGIT> ]
The slash "/" <DIGIT><DIGIT> a year modifier which shows the possible date alternatives for pre-1752 date brought about by a changing of the beginning of the year from MAR to JAN in the English calendar change of 1752, for example, 15 APR 1699/00.

I agree with your general points except that double-dates only apply before the changeover date not afterwards.
Gregorian years are never in doubt as they always begin on 1st Jan.
It is the earlier Julian years that began on 25th Mar that need qualifying with double-dates.

[Mark1834]

I think I got it the right way round. Dual dates apply during that period between when the Gregorian calendar was introduced and the local date of its adoption (particularly by the English who have spent hundreds of years being suspicious of European innovations!). They are to resolve ambiguity about which calendar the date is referenced to, not convert all dates since the dawn of time to Gregorian. So the low limit is 1583 and the high limit varies by country, but 1752 in England and its territories.

[mjashby]

Mark,

The issue of solely considering the overlapping period between the 'old' and the adoption of the 'new' Christian calendars as the sole period to which double dating should be applied is that it ignores a very real issue; i.e. the variable date for the commencement of a 'New Year' for both Christian and non-Christian populations. When considering predominantly Christian countries, in England, for example, from 1087-1155 the New Year did begin on January 1st, but from 1155-1751 it began on 25th March (the start of the financial year) and all available dated documents will reflect that, so what are we to do for the period between 1155 and 1582 if we don't consider double-dating dating to be a 'valid' option? For example, I would have a number of Wills which were signed and witnessed after the person had been buried.

FH does, of course, provide the alternative of assigning [J] dates for any date before the Gregorian Calendar was adopted, but I'm yet to come across very many users.

Mervyn

[Mark1834]

That's an interesting point, Mervyn. However, I think there are actually two separate uses of dual dates. If an early will is dated "1 Feb 1550", it is unambiguous as there was only one calendar in use at the time.

Entering such a date as "1 Feb 1550/51" is simply a workaround to keep events in the correct sequence, as it would not be practical to program FH to recognise every calendar change in every country of the world. What is does is effectively tell FH to pretend that it happened in 1551 for the purposes of sequencing and time interval calculation.

You have persuaded me that prohibition of dates outside a defined range would be wrong, but I still think that a warning should be displayed (with a "don't show this warning again" option) for dates outside this range or ambiguously defined dates such as "1650/51".

A laissez-faire approach seems to be CP policy, as the FH help does say that it is possible to enter invalid dates!

[AdrianBruce]

... If an early will is dated "1 Feb 1550", it is unambiguous as there was only one calendar in use at the time.

Entering such a date as "1 Feb 1550/51" is simply a workaround to keep events in the correct sequence, ...

Um. It's only unambiguous for your interpretation if you are certain that the scribe really was using the official calendar. But that's probably a different problem from... It's only unambiguous for reading if you are certain that your reader understands which calendar is meant.

Given the infamous thread I saw in another place where the explanation of a discrepancy was not that the dates were written in an untrustworthy personal journal but that the dates were single dated and had been converted / perverted to the modern year twice, I think I'd prefer to play safe and double date for clarity, i.e. I'd use it for more than just keeping stuff in the correct sequence.

An interesting thought - if I'm belt-and-bracing my dates - what about my Scottish dates between 1600 and 1752? I think I'd have to note them if they fall into that overlap to say that my Scottish ancestors were ahead of the game - though a quick glance doesn't reveal any pre-1752 dates in the problematic period between Hogmany and Lady Day...

[davidf]

With V7 allowing sort dates - I'm on V6 so just reading the marketing documentation - can we adopt a practice where the date is as per the document and the sort date is our interpretation of what that date would be in the modern (current) calendar?

[RS3100]

Given the infamous thread I saw in another place where the explanation of a discrepancy was not that the dates were written in an untrustworthy personal journal but that the dates were single dated and had been converted / perverted to the modern year twice, I think I'd prefer to play safe and double date for clarity, i.e. I'd use it for more than just keeping stuff in the correct sequence.

Having obtained copies of original register pages and other documents after originally being pointed to the sources by transcripts, I have found several where this has happened, to the extent that I suspect it is not an uncommon occurrence. Some have been instantly obvious where both versions appeared in FMP hints within FH, as transcripts of the same event from different collections.

[Mark1834]

An alternative would be to enter the event date as recorded (1 Feb 1550), so the user does not make any assumptions about what was meant, but also enter a sort date of 1 Feb 1551 for sequencing purposes Perfectly reasonably, sort dates have to be Gregorian calendar, so they are all in the same format for sorting.

The important thing is to be consistent and document your assumptions. (sorry, got distracted by phone call, so didn't read David's post before submitting)

[AdrianBruce]

With V7 allowing sort dates - I'm on V6 so just reading the marketing documentation - can we adopt a practice where the date is as per the document and the sort date is our interpretation of what that date would be in the modern (current) calendar?

And also as per Mark's comment....

In my view this would be a bad idea. Best practice (OK, standard practice then) across genealogy is to double date. Deviating from that standard would come at a price of confusion - not least because if you give someone a printed report, there is no sign of any sort date (unless anyone knows better!).

Of itself, it's not an inherently bad idea - it provides a token that the calendar warp has been done - provided you check the sort date - but the point is that there is already a method used across the board and sort dates are inconsistent with it.

[tatewise]

Just to reinforce that, not only do Sort Dates not usually show in Reports and Diagrams, but also if a GEDCOM is migrated to another product the Sort Dates often won't be imported because they are a non-standard extension.