Gregorian calendar

Question

Does. Db_errors take into account the lost 13 days or other differences between dates of switching calendar ?

Comments

Can you give examples?!?!? Isn't the problem that WikiTree lacks information what calender we are using? 

Calendars are more complex than 13 days.... 

When comparing with WikiData you have in WIkidata the calendar and the Date precision so they have no problems

Example: Bjornsson-178 

WikiTree Born about 0930 in Upsala, Sweden

WikiData Q318912

Birth date is in WikiData P569 and has 

1. a date value +0945-01-01T00:00:00Z
2. with date precision 9 ==> year
3. calendar model Proleptic Gregorian calendar  Q1985727

The whole structure you get for birth date using  wbgetentities 

 

                "P569": [
                    {
                        "mainsnak": {
                            "snaktype": "value",
                            "property": "P569",
                            "datavalue": {
                                "value": {
                                    "time": "+0945-01-01T00:00:00Z",
                                    "timezone": 0,
                                    "before": 0,
                                    "after": 0,
                                    "precision": 9,
                                    "calendarmodel": "http://www.wikidata.org/entity/Q1985727"
                                },
                                "type": "time"
                            },
                            "datatype": "time"
                        },

---

A quick fix to the problem that we dont tell what calendar we us in Wikidata would be that we in WikiTree define a number of calendars and adds a template to the bio section that explains the calendar we use.... or have the Birth date in the correct calendar and form 

{{Calender|xxxxx|Birth}}

==> we use calendar xxxx for the birth

1. Example of calendars defined in Wikipedia 
2. Wikipedia Navigation template Calendar 
3. Wikipedia List_of_calendars

---

The adoption of the Gregorian calendar was not universal. Different countries adopted it at different times, and sometimes changed by gradually adjusting the days. Trying to have one standard to use is probably an impossibility. Personally, I view the date entered on a profile should be what the date in use at the time was. The Gregorian calendar was decreed in 1582, but some countries only adopted in centuries later. Bulgaria, for example, only changed from the Julian calendar in 1917.
I would suggest that date entered on profiles should reflect what an original document states. A conversion from non-Gregorian calendars is likely to be problematic and the resultant date should be marked as approximate.

---

@Paul 
I understand that you favor a solution adding the calendar used to the date found in the original sources...

The Calendar template is now changed to support also the Date see

{{Calendar|Julian calendar|Birth|20 dec 1602}}
{{Calendar|Julian calendar|Date=20 dec 1602}}

Some links on this subject

• jenstad-holmes-encodinghistoricaldates
• Wikipedia Gregorian_calendar#Timeline
• Gedcom X specification
  • GedcomX has both an original date (what the source said, or what conclusion the user wants to draw) and a formal date (useful for search, match, computation, etc., in so much as the original value was parsed and interpreted correctly)

---

Sometimes, especially when using a transcribed source, it is difficult to tell whether a conversion has already been made or not.  I have sometimes found two transcriptions for the same baptism (in Jan, Feb, Mar) one in year N and one in year N+1.  But if you only have one, it can be difficult to tell which is being used.

This refers more to the year than to the 13 days, but the same principle applies.

---

@Janet maybe something like this

{{Calendar|Unknown|Date=20 dec 1602}}

Then at least the reader understands that for this date the calendar is unknown

---

Please don't create and use templates to interpret dates. The past use of "automated" protocols for interpreting dates and "translating" between calendars has contributed to many legacy problems with date information for long-ago ancestors. Adding templates (which at least 90% of WikiTree contributors don't understand, as indicated by the number of people who can't figure out how to remove the "Unsourced" template from a profile) will only add to this legacy.

Some of my thinking on this:

• WikiTree's Gedcom import protocol has created many date errors here by failing to correctly interpret "double dates" in imported gedcoms. A date of 23 February 1692/3 would be entered in the data field as "about 23 February 1692," instead of 23 February 1693. Fortunately, the details were recorded in the text section of the profile, so it can be manually corrected, but it means that many data records here are wrong.
• Going back further in time (this is a made-up description that's not far from some real cases I've seen), a 19th-century genealogist who found a record for 23 February 1692/3 helpfully recorded the date as 23 February 1693 in his published genealogy, to prevent readers from having to deal with double dates. Another 19th-century genealogist who didn't understand double-dating published the record date as 23 February 1692. A third genealogist corrected for the difference in days between the calendars, resulting in a date like 5 March 51692/3 (I've not determined the precise number of days for that year). In the 20th century, various different readers of those published genealogies who read those publications (and didn't check the original records) made different assumptions about what the authors saw in the records, and reinterpreted the dates as 23 February 1691/2, 23 February 1692, 23 February 1692/3, 23 February 1693, 5 March 1692, and 5 March 1693. All of these dates, plus 23 February 1691, ended up in "sources" like the Ancestral File and got imported to WikiTree in multiple duplicate profiles for the person, and have created a large degree of confusion.

To ensure integrity of the information, we need for humans to carefully document dates as reported in the records and describe those dates in WikiTree profiles. (It's also desirable to document the alternative interpretations of the dates that have been reported by other authors.) Fancying things up by using a template to re-interpret the date is a step backward, not forward.

---

@Ellen

This template is not interpreting it just states what calendar a date is using and do it in a machine readable format...

People who has some clue of the calendars and care about more or less exact dates can use it. Other people can continue just adding the dates and it's up to the reader to do a best guess....  

---

I place higher priority on communicating in a human readable format.

---

@Ellen all WikiTree profiles metadata is both readable by human and machine see example your profile Smith-62120 or Smith-70371 as you see no calendar is mentioned which feels like a problem for a World Wide genealogy family Tree....  but we can always guess ;-)

---

@Ellen, I agree butt I don't think they are incompatible. Ultimately I agree with Magnus.

Answer 1

Precise dates are a difficult issue, the first example in [http://www.slideshare.net/JanelleJenstad/jenstad-holmes-encodinghistoricaldates jenstad-holmes-encodinghistoricaldates] is a good example. A journey starts in Netherlands 1688-11-11 and finishes in England 1688-11-05 (earlier). What dates do we enter as information? The dates were recorded as per the system in use in their respective countries. If precision is required then the date stated should have the calendar used also stated.In the above, a reporter in England would say that the journey began BEFORE 1688-11-05 and a reporter in the Netherlands would have different perspective and he would report that the journey ended AFTER 1688-11-11. Each would be using the local calendar in use.
Any conversion to dates consistent with the Gregorian calendar we use today would be dependant of many factors for absolute accuracy. For genealogy purposes I would treat most of those dates as approximate. None of this says that an attempt for accuracy should not be made, just that it is a complicated area.

So, as to the GedcomX spec, yes, it is useful for computational/searching but, as in slide 23 of the Jensted Holmes presentation, the calculated date should be treated as approximate.