Should we automatically rewrite dates like “July 29, 1821” to “29 Jul 1821”?
1 Like
This is something that Family Tree Maker did that I always liked. They had an option to set your preferred format. However, I would be happy with DD Mon YYYY if you want to set one approach. I believe that is the standard format for the NEHGS Register.
1 Like
Ok, any votes to the contrary?
“dd mmm yyyy” is pretty much the standard format for dates in genealogy (not to mention in everyday life for the rest of the world outside the U.S.). I even teach that in beginners’ classes, because it’s what experienced researchers expect to see.
I personally would recommend making that the default display format for the website, regardless of how the info is entered. (And if someone typed in “3/4/1900”, you would have to have a popup or something asking the user whether they meant “March 4th” or “April 3rd.”) WikiTree reformats all dates to display in the “July 29, 1821” format, which drives me crazy.
1 Like
I think you need to present dates in a standard format since the dates will be entered in a variety of ways, particularly if collaboration ever takes place on a tree. The default standard should be 29 Jul 1821, of course. Conceivably a user preference could select an alternative standard (for that user’s view) to be used, but that feature would be near the bottom of my to-do list.
Fantastic idea; a common default, with users able to override to their own preferred format as a mask (as a future endeavour). It is something that has let down other sites in the past.
1 Like
Thank-you for the comments everyone. I’ve added this to the todo list prior to launch in Feb. Trello
I realize this is an old topic, but I have a pertinent question to add: could the auto-formatting include letter case? I ask because all my dates from my original GEDCOM import got converted to all caps (e.g. 7 MAR 1820). I would prefer the month to be only in initial caps (7 Mar 1820). I’ve been changing them by hand as I go through and clean up my data on Rootsfinder, but need I bother?
It looks like the dates in your original GEDCOM are in all-caps. Is that expected? Are you asking that we provide an option to convert all-caps dates to initial-caps on import?
Given that you’ve already imported your tree, it might be best to change the dates by hand.
Yeah, the dates are not in all caps in my Reunion 11 database which created the GEDCOM, but I think Reunion’s GEDCOM converted them to all caps.
I guess I was wondering if there could be an option in the settings of your tree that lets you set a universal date format (including letter case) for your whole tree. A setting to do that upon GEDCOM import would be good too, I guess. I mean, granted, this isn’t a red-alert level issue. I’ve been fixing the date formats by hand as I go through my tree on Rootsfinder, but it is a pain in the butt to have to do that for every single event in a database of over 12K individuals.
I like changing the way dates are displayed better than changing the raw dates that are imported. I hesitate to change the data that comes in from the GEDCOM. Changing how dates are displayed is safer because if you don’t like it for some reason, you can always unset the setting and have dates displayed back in the original format.
I’ll add that to the Roadmap. It’ll hopefully get done in the next few months, so you don’t have to worry about changing things manually.
1 Like
I’d like to add my support to this request. I’d prefer dates to be display in long format (eg 3 March 2018) and also to be able to move dates over to Family Search in this formation, not in 3 MAR 2018.
When there is time to add support for the optional/variable date formatting is it feasible to also provide a format that will show day and then date? ie “Monday, 8 October 2018” or “Monday, October 8, 2018”? Or that gets too involved too quickly?
I could make the date format a selectable choice pretty easily. But when there are ambiguous dates or date ranges, like 1/3/1918 or July 1918 - 1920, or abt 1919, or “1918 or 1920”, I think it’s safest for me to display the actual text that was entered, rather than risk displaying an incorrect date standardization. Would you agree?
Yep, I’d agree, that makes the most sense.