Standard Date assigned to a Display Date Cannot be Removed

LegacyUser

Jeff Wiseman said: In some situations, the editing of an event date relative to the Standard Date assigned to it will appear to be set up and saved in one fashion, but will invisibly be changed to another upon Save. This can be seen in the following sequence when adding a Christening date:







The following then shows the screen just before the Save:



You then see no data error from a non standardized date, so you go back in and look at the same Vital and it has changed:



Behaviors regarding the interaction of display dates and standard dates are presently being discussed elsewhere in this forum. However, this problem is specifically limited to the issue where If you save something into the system and immediately look at it again, you should see exactly what it was that you just saved.

LegacyUser

Gordon Collett said: This is fairly new behavior that started within the past few months. I wonder if this is an intermediate step to changing the programming to what we see in Sources. If you enter a date for a source and choose to not have a standardized value, you cannot save the source:





I suspect the programmers would agree with you completely but have not had a chance to take the next step. It might have been easier to kludge the save in an effort to get rid of non-standardized dates than to cleanly re-write the routine, particularly if they are in the middle of a major re-write to have the detail page and editing boxes match the new merge and Change Log screens.

What ever is really going on, I do agree this should be fixed.

LegacyUser

Jeff Wiseman said: That's a good observation and may be true. But since the explicit "Save" behavior is definitely wrong, I wanted to see if I could get this on the "books"

The ability to select "none of the above" is far more useful (to me, anyway) for place names than for dates. But since I'm rarely in a position to use unusual data standards (I do everything in English and spell out the entire date), I am not knowledgable enough to make observations on what is good or not when it comes to the dual dates system.

LegacyUser

Gordon Collett said: Agreed. Good to have it on record.