I would like to see a date-format option in the settings that is IAW the ISO 8601 standard (2004 version): YYYY-MM-DD; or for less-precise dates YYYY-MM. I understand that this is not perfect, given that RootsMagic (properly) allows dates with prefixs such as “before” and “after”. However, providing a format that allows full dates or year/month to be properly sorted would help with exports from my database that require sorting by date.
3 Likes
Already been asked for many times, not yet happened!
Yes, ISO dates for both input and output !!!
Also note the bug-
In RM preferences, one can choose “Use the system settings” for “Date entry”. However, I have my Windows short-date format set to ISO, yet RM does not recognize ISO dates on input.
@RichardOtter --that because there is a 2nd setting in the database settings UNDER the gear that says DATE FORMAT and ISO dates are NOT LISTED even though Use the system setting is under the 3 lines–so it is defaulting to whatever you have picked under the gear…
@shorero
I’m just wondering what you are sorting and exporting that you need ISO dates— hate to say it BUT-- ISO dates MAYBE the International standard BUT not EVERYONE KNOWS abt this or deals with it on a daily basis and I will just say this
as for the the United States Iso dates are NOT a COMMON PRACTICE IN GENEALOGY— I have seen a few people use them in their genealogy databases a while back ( think even before 2004) BUT then everybody else was left wondering well is the date they are referencing May 10 or Oct 5? as there is nothing to say they are using ISO dates–also recently found one old document ( before 1900) in a set of records that used the ISO format BUT it was the only one found and once again I was left wondering abt the month and date BECAUSE the records were not chronological.
I’m certainly familiar with the setting you mentioned for output format.
I’m talking about input format.
I’m surprised that there would be any confusion. The format yyyy-mm-dd is the ISO8601 format. There is no established format yyyy-dd-mm. You may be conflating with ISO8601 formats such as 05/10 which are ambiguous and is the very problem that ISO8601 was developed to resolve. If it begins with yyyy and the month and day are two digits and a hyphen is the separator, it is ISO8601.
Under the hood of RM, the database stores event dates in a strict, position-dependent format that encodes the modifiers along with the date, the latter in the format yyyymmdd, regardless of the Date setting. The Date setting controls how the date is displayed or printed.
Because ISO8601 is an international standard and one adopted by all English-speaking countries, RM should support it as a format for data entry and as an option for output. That said, there is need for granularity in the settings. For example, a user may want ISO8601 for GEDCOM and list reports but a different format for narrative reports.
I absolutely agree that the ISO format is not used (or at least not common) in genealogy databases. In fact, I would probably not use ISO generally as my display format. However, the RM9 report writer allows export in a CSV format, which is handy for importing into a spreadsheet. This is really useful if the report is generating one line per person; for example, name, birth date/place, and death date/place. Sometimes I want to view in birth-date order, sometimes in death date order; but sorting by date is not possible without some programming to extract the day, month, and year fields. Using an ISO format makes these dates sortable, at least for dates without a modifier.
Speaking of modifiers… to make an ISO date format maximally useful, the modifiers should be a suffix rather than a prefix to the ISO date. This would make all single-value dates sortable, regardless of modifier. This trick would even make the dual-date modifiers sortable; BETWEEN and FROM would start with a sortable date if the modifier becomes a suffix, and “-” (dash) and OR already start with a date value and would thus be sortable. I absolutely agree that this would be a terrible way to display dates generally; I’m simply trying to get an output format that I could sort without a lot of contortions.
1 Like
When I am reading about or recording an event date, the first thing I want to know is which millennium I am in. Then the century and next the decade. The first thing I need is usually not the day.
Generally, the complete date string can be 8 numerals long without separators. If it is only 6 numerals, I am reading a year and month to localize the event in time. If the length is 4 characters with no separator, it is for a year. If the date is 2, 3, or 4 characters with a separator, I am looking at a month and day with the month first.
When reading a biography or history, the repetition of the 4 digit year with every event within a decade would be tedious and non-productive. Context can permit a lot of flexibility including the use of an apostrophe for missing parts.
Now is 20240509130615ET. Without a doubt, it is easily sortable.
(yyyymmddhhmmss Eastern Time which is EDT because of local law.)
This is a fun discussion, but the genealogy standard is pretty well set.
If RM would output the SortDate value that it stores internally, you could have the ‘friendly’ date format that you have chosen in Settings in one column of a list of events report and the purely numerical representation in the SortDate column. Then, if viewed in spreadsheet software, you could sort on any column as needed and the SortDate column could reorder events chronologically as a primary or secondary sort criterion.
RM does not do so. Therefore that would be an enhancement request you could make.
Adding the sort date as a report field would work IF the sort date were in Y-M-D ISO format. It’s not clear to ma how the sort date is stored internally; if, for example, it’s a DATE-type field in the database, then the underlying DBMS is handling the sorting-by-date functions, which would explain why it’s a separate field. In any case, using the sort date in an ISO format would definitely solve my problem.
Just an observation. For merely data entry purposes, the full YYYYMMDD (no dash separators) version produces the same result as the other entry formats. Not so for YYYYMM.
Thanks for mentioned by this
Tom was talking about the internal format sort date.
I have been working on a Python script to encode and decide internal format sort dates. I’m finding it quite complicated.
In addition to Richard’s Python scripts, this may help: Advanced Date Algorithms by R. Steven Turley
Agree - IF the software treats the value as a number. If you coerce the data into text, then it’ll sort properly.
I didn’t coerce the data into text. I entered the value as a number (20240511).
EDIT: Oh, you must be talking about external manipulation of the database.
Yes, all those potential input method formats within the program are then parsed into the database construct for RM’s sort key representation.
This is why ISO-8601 makes sense for most situations. We read left to right and reading the most significant information first makes the most sense.
We we have a numerical value 123,456 we don’t say “six and one hundred and twenty three thousand and four hundred and fifty”.
Yes, we read left-right.But when comparing a burial date for Wednesday or Thursday, we don’t need to read millenium-century-decade-year-month everytime we talk about it. This is where conext and apostrophes are useful. Sometimes we want to say June 6 compared to June 7. Or should that be 6 June compared to 7 June. Context will tell us if it the the day or the month we are discussing
And then there is tradition and convention. The QWERTY keyboard is not the most efficient, but everybody uses it. A numeric key-pad is inverted between calculator and telephone.
My compromise is to use ISO internally in my file names, report headings, and Google Mail. All places I might want to sort or search. Then I open the genealogy program to something else.
Example: “Masterson, George & Ernstene-19370317-Los Angeles, CA-Wedding-dressed.jpg”
This image is dated 17 March 1937 in order of significance. The surname is first because Genealogy is about people. Then we put them chronological order by ISO date. Then place. Then event. Then notes. I see this as decreasing significance and increasing focus, left to right. Sharp focus on the bridal bouquet is less significant in history than the place of the event. The bride might want to reverse the priority.