17 replies to this topic

[jwcalvert]

Hi everyone ( and developers ),

 

I have just purchased the RootsMagic 7 software and I am now beginning to enter people.

 

Everything seemed to be going quite well until I entered my first date and it was rejected.

 

In all of my work and other applications,  I only use a date with a format of:     YYYY.MM.DD      eg. 2017.12.25

And I have my system date format on the computer set to the very same format.

 

Is there any way that I can begin using this format with RM 7??

 

Is this a feature that will soon be added to RM 7?

 

I don't want to add lots of people and face a huge effort to deal with unfamiliar dates.

 

Many thanks

Jim Calvert

 

[TomH]

No, you cannot use that format.

Not likely that it will soon be added to RM. Where in the world is YYYY.MM.DD even a standard format? The international standard is YYYY-MM-DD.

[jwcalvert]

Tom,

You are correct.

YYYY-MM-DD is the international standard recognized in Europe, Canada and pretty much everywhere in the world except in the USA.

 

I am really more concerned with the order of the numbers and I could work equally with dot, dash or slashes if needed.

 

Cheers

[Jerry Bryan]

I make my generic and standard comment that RM and all other genealogy software need to separate the way data is stored from the way data is displayed. And the way data is displayed needs to have lots of options and to be under user control. Sadly, almost no genealogy software follows this advice.

 

In the case of dates, genealogy software needs to accommodate various American and international standards, various punctuation (dots vs. dashes vs. slashes), various ways to display approximate date and date range (before, after, between, about, ca., etc.), quarterly dates, Quaker dates, dates in various languages (e.g., for names of months in French or English or German or whatever), pre and post Gregorian dates, various orderings for the day-month-year, full months vs.abbreviated months, and probably lots of other variations on displaying dates that I'm not thinking of right now.

 

If date storage and date display could be separated in this fashion, it should be possible to have very good interchange of date data between different genealogy software and each user could still display dates in the style and language that would meet their needs. Of course, I'm assuming that the standard for storing date data would be a good quality and comprehensive standard and wouldn't be totally horrible the way the current place name standard is totally horrible.

 

Jerry

 

[zhangrau]

If the date is stored as a serial number, where today is 43094 (aka 24 Dec 2017), then shouldn't the display in alternate format just require two things?

  1  -- a powerful and complex algorithm for date conversion

  2  -- a sub-screen under Tools > Program Options for the user selection

 

By the way, the reason that I prefer dd mmm yyyy is because it avoids this type of confusion:
 

    does 3-5-2017 represent 03 May 2017 or 05 Mar 2017 ?????

[TomH]

There are four different formats used for storing dates in a RootsMagic database, depending on the application, as described in Date Formats. Event dates, which are the ones most of interest in this discussion are in a text field that accommodates 2 dates for ranges and modifiers for each. A simple example:

"1 Jan 1900" is stored as "D.+19000101..+00000000.."

 

The issue is the formats supported for data entry and display do not include languages other than English nor many other non-US formats, including the ISO standard "yyyy-mm-dd".

[Jerry Bryan]

If the date is stored as a serial number, where today is 43094 (aka 24 Dec 2017), then shouldn't the display in alternate format just require two things?

 

This is the basic idea I'm talking about - storing the date separately from the formatting info for the date. But the storing the date part has to be more comprehensive than storing the date as a serial number for a specific month and day and year. That's because you sometimes don't have the day and sometimes you don't have the month. If somebody was born in 1852 (info from a tombstone and that's all  you have), there is no specific serial number for a month and day and year that will work. The same thing is true if all you have is that somebody was born Aug 1852.

 

RM already stores "year only" dates in an unambiguous fashion and it already stores "year and month only" dates in an unambiguous fashion. RM cannot presently store "year and quarter only" dates in a reasonable fashion (e.g., 3Q 1852). I'm less sure about whether or not RM can store Quaker dates and pre-Gregorian dates in a reasonable fashion. I think RM could (and probably does) handle Quaker dates satisfactorily if you convert them yourself to standard dates as you are entering them. One problem with Gregorian dates is not all the world converted from Julian dates go Gregorian dates at the same time.

 

Jerry

[TwoScoops]

I have the same Date Format problem.

I wanted to print a name list with RIN and Date Format  yyyy-mm-dd

A way around this is via Ancestral Quest 15. (Basic Free Version)

 

Import   RM File into AQ15 

Select  Tools/Preferences 

Select   Formats Tab

 

Various date formats are on right.

List can then be printed as required.

 

Hope this fits the bill.

[Vyger]

I have the same Date Format problem.

I wanted to print a name list with RIN and Date Format  yyyy-mm-dd

A way around this is via Ancestral Quest 15. (Basic Free Version)

 

Import   RM File into AQ15 

Select  Tools/Preferences 

Select   Formats Tab

 

Various date formats are on right.

List can then be printed as required.

 

Hope this fits the bill.

 

A date will always appear the same in the database tables and I can't see massive changes to suit personal preferences.

 

I see this as more of a display and reporting facility which could be accomodated if Rootsmagic sees merit in it. If I want particular sorts which are not available in Rootsmagic I export to Excel and split the date components there.

[TwoScoops]

 

A date will always appear the same in the database tables and I can't see massive changes to suit personal preferences.

 

I see this as more of a display and reporting facility which could be accomodated if Rootsmagic sees merit in it. If I want particular sorts which are not available in Rootsmagic I export to Excel and split the date components there.

I have done that, but I find AQ15 is easier.

 

Yes, I use it just for report listings.

 

I find it a lot easier to identify a date in the format yyyy-mm-dd

when reviewing and document filing.

 

I would welcome this format in RM

[deckie49]

Jim,

FYI, here is a link explaining the GEDCOM Date TAG and all the acceptable formats. That should be your guide. Even if you found a program that would allow you to enter your date the way you want, if it isn't GEDCOM compliant it would just create problems.

 

http://wiki-en.genea...OM/DATE-Tag#Tag

[Trebor22]

 

By the way, the reason that I prefer dd mmm yyyy is because it avoids this type of confusion:
 

    does 3-5-2017 represent 03 May 2017 or 05 Mar 2017 ?????

While personal preference might be OK elsewhere I believe the format  zahangrau cites is by far the best way to avoid confusion for for family history purposes.

[Vyger]

By the way, the reason that I prefer dd mmm yyyy is because it avoids this type of confusion:

 

    does 3-5-2017 represent 03 May 2017 or 05 Mar 2017 ?????

 

Looking at this post again I realized I use yyyy-mmm-dd in file naming for sort purposes but I can parse that out anyway I want and would not wish to have RM dispplay dates any differently. zhangrau is correct to point out the importance of mmm in the date to avoid the international misunderstanding which might result, I have needed to correct many files in the past die to this.

[TomH]

Jim,

FYI, here is a link explaining the GEDCOM Date TAG and all the acceptable formats. That should be your guide. Even if you found a program that would allow you to enter your date the way you want, if it isn't GEDCOM compliant it would just create problems.

 

http://wiki-en.genea...OM/DATE-Tag#Tag

 

Not so. Display and export are independent of the stored format. So display could be in a format that is not GEDCOM compliant but the app would have to export and import in compliance. Otherwise, avoid that app - it's stuck in the 80's.

[TwoScoops]

 

Not so. Display and export are independent of the stored format. So display could be in a format that is not GEDCOM compliant but the app would have to export and import in compliance. Otherwise, avoid that app - it's stuck in the 80's.

Yes I was thinking that way.

 

I only use date format for listing/printing/review, that's where AQ15 comes in.

 

It is easier / quicker to notice date similarities when data is listed  yyyy-mm-dd OR yyy-mmm-dd  

 

The international format defined by ISO (ISO 8601)

 

https://www.w3.org/QA/Tips/iso-date

[mjashby]

How does that format cope with and provide clarity with 'dual dating', e.g. 06 Mar 1655/56?

How does it clearly identify whether a date prior to 1752 came from the Julian Calendar, or has been 'transposed' to a Gregorian date; which would, if calculated correctly, be completely different, to what was recorded in the original document?

How does it handle 'Quaker Dates' prior to 1752, where Month 1 (i) was March & 10 ('x') was December?

 

No wholly numeric system can provide complete clarity and I don't see how ISO 8601 could possibly be successfully applied to the recording of all historic dates, or to any Calendar that does not/did not conform to a general European/US perspective/modern expectation. This difficulty applies particularly where calendar inconsistencies existed (and continue to exist) and/or where there were clear historic differences in calendar usage, e.g. the Gregorian Calendar was not 'universally' implemented across Europe on a single date, That change wasn't even implemented across the 'Great Britain' in the same year, as Scotland accepted the Pope's decree on the implementation date for the Gregorian Calendar, but England & Wales (and the 'Colonies') didn't.

[TwoScoops]

Each date format has it's merits.

 

I explained how I got the date to format in a manner that suits me ( yyyy-mm-dd )  , so others could benefit.

 

Having the Option to display date as yyyy-mm-dd, as does other software, would be a bonus.

 

It's only an "Option" to "Display" or "Print" feature, not a total programme re-working.

[deckie49]

 

Not so. Display and export are independent of the stored format. So display could be in a format that is not GEDCOM compliant but the app would have to export and import in compliance. Otherwise, avoid that app - it's stuck in the 80's.

Tom,

Thanks for the clarification!