Dates incorrectly parsed when tenant locale != American English

Overview
When a tenant uses a locale other than "American English" dates entered into date field in Agreements or Licenses
Steps to Reproduce:

1. In the Settings app select Tenant > Language and localization. NB If using the hosted reference environments PLEASE use the option to set a temporary session locale by using:
   Settings -> Developer -> Session local
2. Change the Locale from American English / American English to British English / British English
3. In the agreements app create New agreement
4. Enter a date which is only valid in the British English date format - e.g. 16/09/2020 (i.e. this cannot be interpreted as MM/DD/YYYY). Date can be entered by EITHER

• choosing from the date picker OR
• typing a date using the British English format (as prompted by the placeholder) of dd/mm/yyyy

Expected Results:
Date correctly recognised and parsed as a valid date having been entered in the british date format mm/dd/yyyy

Actual Results:
Date not correctly recognised/parsed

bundle.c61d3738bf6906888827.js:417 Uncaught TypeError: Cannot read property 'substring' of null
    at outputFormatter (bundle.c61d3738bf6906888827.js:417)
    at t (bundle.c61d3738bf6906888827.js:417)
    at onChange (bundle.c61d3738bf6906888827.js:417)
    at i.value (bundle.c61d3738bf6906888827.js:330)
    at Object.c (bundle.c61d3738bf6906888827.js:360)
    at p (bundle.c61d3738bf6906888827.js:360)
    at bundle.c61d3738bf6906888827.js:360
    at b (bundle.c61d3738bf6906888827.js:360)
    at it (bundle.c61d3738bf6906888827.js:360)
    at Array.forEach (<anonymous>)
outputFormatter @ bundle.c61d3738bf6906888827.js:417
t @ bundle.c61d3738bf6906888827.js:417
onChange @ bundle.c61d3738bf6906888827.js:417
value @ bundle.c61d3738bf6906888827.js:330
c @ bundle.c61d3738bf6906888827.js:360
p @ bundle.c61d3738bf6906888827.js:360
(anonymous) @ bundle.c61d3738bf6906888827.js:360
b @ bundle.c61d3738bf6906888827.js:360
it @ bundle.c61d3738bf6906888827.js:360
at @ bundle.c61d3738bf6906888827.js:360
ct @ bundle.c61d3738bf6906888827.js:360
pt @ bundle.c61d3738bf6906888827.js:360
ae @ bundle.c61d3738bf6906888827.js:360
se @ bundle.c61d3738bf6906888827.js:360
Jt @ bundle.c61d3738bf6906888827.js:360
$t @ bundle.c61d3738bf6906888827.js:360
t.unstable_runWithPriority @ bundle.c61d3738bf6906888827.js:368
Va @ bundle.c61d3738bf6906888827.js:360
ne @ bundle.c61d3738bf6906888827.js:360
Xt @ bundle.c61d3738bf6906888827.js:360

Additional Information:

• If the date is picked from the date picker the same issue occurs
• If a date that can be a valid date when parsed as a US date (mm/dd/yyyy) is entered then it is parsed as a US date - e.g. try entering "01/09/2020" is parsed to 09/01/2020 - and displayed back to the user. If the user then saves the record, the date recorded in the database is "2020-01-09" (i.e. 9th of January rather than 1st of September as the user tried to enter). This means that the value entered/selected by the user (01/09/2020 - 1st September) is being (for some reason) converted to the US date format (09/01/2020 - this is the correct date in US format - still 1st September) within the form field, but then when the form data is submitted to the database it is being interpreted as in British date format (due to the locale presumably), and so the eventual date written in the db is 9th January instead
• The locale/language of the browser doesn't seem to affect the behaviour one way or the other (tried the above with the Chrome Language set to US and to British English)