Allow “dates” to be entered as timestamps that adhere to ISO 8601.

My Rationale

Within the properties of contacts, I hate entering dates as 03 Mar 1922, because that format is significantly more slow than 1922-03-03 or 19220303 and requires more mental thought. Additionally, I have actually been unable to manually enter any dates, presumably because I have been unable to ascertain the format of them, which causes me to utilise the picker when I want to. This is awful.

My Desired Solution

Allow dates to be entered as timestamps that are adherent to ISO 8601, especially within properties of contacts.

Considered Alternatives

Potentially, entry of dates that are adherent to the relevant locale. I don't know why these would be chosen, because they aren't objectively worse, and do not provide any of the benefits that are undermentioned.

Additional Context

This would be a brilliant chance to allow times to be added to the dates, so that they become timestamps rather than mere dates. Time is able to be infinitely specific because obviously decimal values are utilised when seconds are not specific enough, whereas solely dates are almost useless if anything is important is to be stored. Times should be entered as 1922-03-03T23:04:12+01:00 or 19220303T230412+0100. The first section is the date, the section after T the time, and the section after + the timezone. Addition of the timezone is especially important because dates are ultimately reliant upon time, and without knowledge of the relevant timezone, a date is able to have occurred and simultaneously not occurred for a few hours during night. For celebrations, that is bothersome.

No files or tests are named. Start by locating the contact property date input and its parsing and validation path, then determine how manual entry currently differs from the picker. Done means the supported ISO 8601 date and timestamp forms, including timezone handling, are defined and covered by appropriate tests.