The call shown in the error output is, for example:
date2sql('2025-01-01')

date2sql() obtains the current separator using:
$sep = $SysPrefs->dateseps[user_date_sep()];

and for the YYYYMMDD date format eventually executes:
list($year, $month, $day) = explode($sep, $date_);

user_date_sep() in includes/current_user.inc gets the separator from the current session:
return isset($_SESSION["wa_current_user"]->prefs->date_sep)
    ? $_SESSION["wa_current_user"]->prefs->date_sep()
    : $SysPrefs->dflt_date_sep;

Therefore the stale company A page submits 2025-01-01, while the current session expects /. This effectively results in:
explode('/', '2025-01-01')

which explains the warnings.
Expected result
A page generated in the context of company A should not silently be processed in the context of company B after the active session company has changed.
Ideally, each submitted form/request should contain enough information to verify that the company context in which the page was generated still matches the current session company. If it does not match, FrontAccounting should reject the request and ask the user to reload the page.
Why I think this is more important than the date parsing warning
The different date separators made the problem visible. If both companies had identical date settings, this particular request might apparently succeed and there would be no obvious indication that a page generated under company A was being processed using company B's current session context.
I have reproduced the context mismatch with Journal Inquiry. I have not tested submitting an accounting transaction from such a stale tab because I do not want to risk modifying the wrong company's data. Therefore I cannot say that cross-company writes are possible, but I think this should be checked because it could represent a data-integrity issue.
Version: FrontAccounting 2.4.20
I can provide a screenshot showing the complete PHP warnings and the stale Journal Inquiry page if useful.