I’d appreciate being able to use variations of the ISO 8601 date (and time) standards in fields that take dates (and times). I am especially keen to be able to enter all dates using YYYY-MM-DD format.
–
JJW
2 Likes
well – how you enter and how RM stores (internally) are not the same thing necessarily.
The dates for events are store to account for About / between and so on – so it needs to be cover-ted first before most software can make use externally.
Let me amend my comment. I can enter YYYY-MM-DD. It seems that RM cannot recognize this format in its settings …
… and it seems that RM cannot work with this format for calculations with date fields. For example, does the GOLD color in the date field below indicate an error? And, when I enter May 1, 2026 instead, the Sort date field carries over that date.
–
JJW
The gold font means it’s considered a text date and is not used in calculations.
1 Like
I second this feature request.
ISO 8601 is how I normally write dates and name files (to facilitate chronological sorting). Fairly atypical for an American, but there you have it.
2 Likes
Yes, and I’d like to see RM allow output of dates in ISO format as well.
Easily done in SWLite.
1 Like
The lexicographical (alphabetical) sortability of an ISO date format is definitely a visual/logical aid for humans and has benefits in some applications, especially for tabular data, but the format has its own problems. Those dates are only valid for the Gregorian Calendar. So, Julian Calendar events suffer from a few programmatic difficulties …like differing years of adoption, which month begins that year, and thus, the calculations and conversions that then require having to literally transition between the two and display/convey, with human understanding, that those calendar changes have taken place and why … those dates/years differ from the original human input.
My guess is that’s why there’s a varied and somewhat robust set of date expression modifiers that are part of a system for the specific date formats to be visualized. SQLite (the database format) doesn’t have a dedicated Date data-type and as was mentioned above, RM internally does notgenerally use lexicographic means to store and work with dates.
ah yes I misunderstood.
Any accepted date is stored the same way behind the scenes. If date has special characters or wrong use of about between etc it will not be usable for calculations etc. This can be true if entering or if came from import/Gedcom etc