Proposal: Correction to the Help:Date Field page

Question

The Help:Date Field page in the Julian vs Gregorian Calendar section incorrectly states how dates are handled.  It suggests that we should be changing Julian calendar dates to Gregorian calendar dates.  This is wrong and is actually causing some confusion on WikiTree.  To truly do this, we would need to not only adjust the New Year start date from March 25 to January 1, but would also need to shift the date by 9/10/11 days.

To clarify how dates are handled by both historians and genealogists, I want to change the

• Current Julian vs Gregorian Calendar section to a
• Calendar Adjustments section.

I kept the proposed change to a very straight forward set of rules, so as to not be confusing.  I have also written this more comprehensive page on a Dates, Calendars and Genealogy page where I could discuss the Gregorian vs Julian calendars, Old Style vs New Style, Double Dating, etc. and the problems these different calendars cause.

Comments

Joe, thank you for taking on so many things at once.  Good luck!

Answer 1

Your 'Rule 3' seems a little wordy, as compared with what is already there i.e. ONE sentence:
"Here is a simple rule of thumb for the most common case: If you see a date from the 1600s or 1700s that has a slash in it, e.g. 1718/19, use the later of the two dates, e.g. 1719."

This also removes the need for adjusting and shifting which you propose.
 

Comments

I think the present wording is  missleading .The 'simple rule of thumb'  suggests  that the most common case is finding a double date. I've only rarely seen a parish register with a double date for the period Jan to 24 March. I don't think I have ever seen a will that uses that format.

 I do think it's  important to adjust the 'start' of the year to January  since leaving it as written can lead to all sorts of confusion. It's hard to explain though

I like this visual illustration of why we should make the adjustment.

https://images.findagrave.com/photos/2008/254/29738313_122118317705.jpg

The gravestone of  Thomas Lambert in Salisbury Cathedral.  He was born May 1683, died Feb  'the same year ' . In baby Thomas's case May 1683 and  Feb 1684 would go in the date field and he wouldn't appear to have died before he was born

---

That's a great gravestone Helen.

I think my rule 3 is one sentence. "For dates requiring double dating, the new style (larger) year should be in the data field, while the double date should appear in the narrative biography." I just added an example to make it extra clear.  I added a break so the example doesn't make it look so wordy.

I agree with Helen that I don't necessarily like your sentence either Ros, as the vast majority or records don't actually provide a double date.  I am open to better wording though if anyone has one.

---

It wasn't actually 'my' sentence.  It was copy and pasted from the Help page itself.

---

I found a better picture of that gravestone and added it to the Dates, Calendars and Genealogy page as well as the profile of Thomas Lambert.  Thanks Helen for the example.

Interestingly, someone had changed his death date in the data field to the Gregorian date of 29 February, further illustrating the problems on WikiTree of handling these calendars.

Answer 2

It is not wrong to translate a Julian date to Gregorian, it is just a way to record a date. You could for example also translate an Islamic date or a Unix-time to a Gregorian date.

At this moment, the meaning of the date field is the date in the Gregorian calendar, not the Julian, Islamic, Hebrew, Ethiopian, etc. This is why a translation is needed. The main problem is that the translation has to be made manually, which is very error-prone, while it could easily be made automatically by the software.

I think when this proposal is approved, the calendar used for the date should also be stored with the date. This prevents ambiguity about which day the date refers to. We have more than three centuries where both calendars where used alongside each other, depending on the place where you live. The 'calendar boundary' even split countries like the Netherlands for over a century.

Comments

If we say to translate the date then billions of records are wrong.  It means that every single recorded date in every parish register and every government document is wrong.

If  parish register says that someone was born on April 4th, then that is what we put.  We do not say they were born on April 14th.  How confusing would that be?

I certainly recognize the issue can be even more confusing in certain countries and in certain time periods.  This is especially true for the Netherlands who went back and forth between the calendars for a time, and for Germany where different parts of the country adopted the Gregorian calendar at different times.

---

Yes it's indeed confusing to use only Gregorian dates in places where the Julian calendar was used, but the same could be said for dates in the Ethiopian calendar that are about 8 years off from our calendar.

"It means that every single recorded date in every parish register and every government document is wrong."

It's not wrong. It just uses another calendar. The Russian orthodox church celebrated Christmas on 7 January this year. They call that 25 December. That doesn't mean they're wrong. They just use another calendar.

"is especially true for the Netherlands who went back and forth between the calendars for a time"

Different regions in the Netherlands switched at a different time between 1583 and 1701. We didn't switch back to Julian.

I think the proposal is good in the sense that a date recorded in the Julian calendar should preferably entered and displayed as a Julian date, but the information which calendar is used should then be stored and displayed alongside the date. This way it's clear which day is meant.

---

You are just making something complicated vastly more complicated.  The point of this is to provide guidance for what to put in the data field based on records.  People are taking English parish records and changing the date from what is in the record.  This is wrong. We don't change the date from Julian to Gregorian; we do change the year from Old Style to New Style.  We make this clear by the practice of double dating.

With regard to the Netherlands, I have:
10 Feb 1583 was followed by 21 Feb 1583
Went back to Julian in the summer of 1594
31 Dec 1700 was followed by 12 Jan 1701

Gelderland: 30 Jun 1700 was followed by 12 Jul 1700
Utrecht and Overijssel: 30 Nov 1700 was followed by 12 Dec 1700
Friesland: 31 Dec 1700 was followed by 12 Jan 1701
Drenthe: 30 Apr 1701 was followed by 12 May 1701

So, according to the website I was following for the Netherlands, they did briefly use the Gregorian calendar from 1583 to 1594 before going back to the Julian calendar, and did not adopt the Gregorian calendar again until 1700-1701.

We are never going to get WikiTree to store and display which calendar is being used.  I am just trying to make this issue as easy as possible for people because it is causing confusion.

---

I believe what is happening with regard to the 1583 date and the switching back, is my site is referring to Belgium which was then part of the Netherlands?

---

At this time the Netherlands (including Belgium) were in their independence war with Spain. This war was also about religion, so the calendar introduced by the pope wasn't liked by most protestants, except Holland and Zeeland who saw the reason for change. Brabant was aligned with catholic Spain in 1582-1583 and with them most of Belgium. So they switched in those years.

All Dutch information I find about the switch, including this page on the website of the 'Royal Dutch Academy of Science', gives different dates per region, but no switching back.

---

"We don't change the date from Julian to Gregorian"

I think it's a bit complicated to convert all dates, but if a date field has the meaning 'Gregorian date', then we should change that date from any calendar we use (Julian, but also Islamic, Hebrew, ..) to Gregorian.

"We are never going to get WikiTree to store and display which calendar is being used."

I think that's the reason the date field means 'date in Gregorian calendar'. If you want to store a date, then you need to know which calendar is used. Otherwise the date could have different meanings. By not storing this information, the date field can only store dates unambiguously in just one calendar system. The chosen calendar is Gregorian.

---

The chosen calendar is not Gregorian, and that is the point.  We can't define the date field that precisely without causing confusion.  Why is this hard?  The date is what you find in the record; we use double dating when their may be confusion regarding the year start date being March 25 or January 1.

I will change the wording regarding the Netherlands.  The idea is decrease confusion, not create more.

Remember this is a basic help page for your average user who just wants to know what to put in the field.  It is not meant to be a history lesson.

---

"The chosen calendar is not Gregorian, and that is the point."

It is stated on the current help page that we should translate the date. So currently the chosen calendar is Gregorian. However you want to change the page, after which the date field will become both Julian and Gregorian. Then it will become ambiguous which calendar is used.

"we use double dating when their may be confusion regarding the year start date being March 25 or January 1."

I think this is something that's only relevant in the United Kingdom and its colonies. In most countries the year already started at 1 January.

---

"I think this is something that's only relevant in the United Kingdom and its colonies. In most countries the year already started at 1 January."

Good.  So there is no confusion, and you don't need to worry about it.  In no country is it standard practice to change the date found in a record from one calendar to another.

Answer 3

Joe, I'm sorry to come to this discussion six days late.

You ask why is this hard?  How about making it easy then?  Get rid of everything but your first sentence of Rule 1:  We use the day and month found on the document.  What could be simpler?  We don't change the dates!

I had to laugh at your statement "[this] is not meant to be a history lesson."  What are we doing here on WikiTree if not trying to teach people a little history?

As for the unusual example of the infant born in May and dying in February of the same year, it would have made perfect sense to the people of the time.  As for us, a little mental exercise (in figuring it out) shouldn't be too painful.

Not everything on a profile needs to be contained in the data fields.  That's what the narrative section is for.  So in the narrative we just explain whether the date is Old Style or New Style.  Simple!

Comments

How would you propose I add 28d 12m 1703 (Quaker style dates) to a WikiTree data field? That’s what the record says, after all.  

What about the date validation and date check errors WikiTree throws us to prevent duplicates and that catch mistakes like mother dead before birth date of her child?

Database fields have to have some consistency to take advantage of database functions.

---

Thank you for asking!  Obviously, you need to convert the Quaker date, because they use numbers in place of month names.  For the rest of it, I don't see a problem.

Any WikiTree suggestion can be responded to in several ways.  You can add a comment and an explanation, or you can mark a suggestion as a false suggestion, ideally then explaining that both in the field provided for the suggestion and on the profile.  Suggestions are not laws, they are helpful hints.

---

Okay...but... that wouldn’t follow your proposed language. 

 We use the day and month found on the document. What could be simpler?  We don't change the dates. 

For documents which do use the slash (it was common enough in colonial New Jersey for me to have seen it in wills and Quaker records), I am not able to use a slash in the date field. Do you think WikiTree should enable the use of slash marks so we “don’t change the dates”? Or follow some straightforward advice to convert a 1722/3 date to 1723?

If I am adding a DOD based on a probate in which the inventory was dated 20 Feb 1724 (new style) and the paperwork settling the estate was settled on 1 Mar 1723 (old style), when did they die? To make my life easier, I would like a rule like the proposal that tells me I should use before 1 Mar 1724. 

---

If we didn't use the convention of adjusting the year, for those Jan-March 24th dates, we would also. conflict  with history books. I've used the example a lot but when did King Charles 1 die? (Check the year  as  written on his death warrant (transcript ) and compare that with the date used in every account of his execution.

---

Heather, one of my next questions was going to be which date should be used when double dating is encountered.  My own initial feeling is that I'd like to see the earlier date, because that is what probably existed in the original record (not sure where you encounter double dating, or whether it is an original record); elsewhere in this thread I think someone commented that he had not seen it much in practice.

I wonder when and where you might encounter a discrepancy such as you've mentioned (estate inventory and settlement), but I still don't find it a huge problem when the basis of dating is disclosed in the narrative.

Helen, it wouldn't be the first time WikiTree has conflicted with the history books.  

I would like to see some established standard for which of the years in the double date should be used.  It would be nice if there was something in actual practice that we could refer to.

---

Heather, I misspoke above.  I would not call changing a Quaker date (with a numbered month) to our conventional usage (named month) converting.  I would call it translating.