yyyy/mm/dd instead expected dd/mm/yyyy format in PHP-created-HTML output
I have an HTML-PHP-CSS contact form with a date field:
<input type="date" name="date" id="cf_input_date"></input>
- The default value in this field is the W3C built-in default:
dd/mm/yyyy - The date-picking pattern in this field is the W3C built-in default
dd/mm/yyyy
My problem
Everything was allegedly fine until I printed this HTML as output to my email box (via PHP).
In my email box, the output pattern for picked dates is the exact opposite of the pattern I already use in the form:
yyyy/mm/dd
Things I have tried to solve it
-
dir="ltr"ordir="rtl"attributes-values anddirection: ltrordirection: rtlproperties-values don't help in flipping the output - Various CSS tricks all ended in failure
- Sadly I can't use JavaScript comfortably in this case because the email output appears in a third party email client which doesn't easily allow JavaScript manipulation of the DOM
My question
How to ensure that my HTML-PHP output is in dd/mm/yyyy pattern (as default for the input field itself) instead the "flipped" yyyy/mm/dd?
1 answer
The date is sent in the form submission in ISO 8601 format (year-month-day). You can reformat it in the form handler as follows:
$input_date = $_REQUEST['cf_input_date'];
if ($input_date)
{
$input_date = DateTime::createFromFormat("Y-m-d", $input_date)->format("d/m/Y");
}
2 comments
Sadly the email client automatically changes everything to yyyy-mm-dd format... If I could control the (PHP?) of my email client --- Roundcube, I guess that then it would surly help...
@JohnDoea, I find that hard to believe and suspect that you're misdiagnosing the problem, but I don't think anyone can take this further unless you post at least some of the form handler (probably complete with logging statements and log output to show the formats before and after key steps).
10 comments
According to MDN, the displayed format of
input type=datecan change according to the browser's locale. My guess is that mail clients might do something similar when interpreting HTML. Not sure if this can be changed (without some JS running on client side). Anyway, when submitted, the value is always sent in ISO 8601 format (yyyy-mm-dd, regardless of the displayed format), which can be properly handled at the backend — hkotsubo 7 days agoHello @hkotsubo, I don't understand why this ISO standard developers wanted to started from the end :) Also, sadly I almost don't have control about the backend of the email client and use it pretty much "out of box". — JohnDoea 7 days ago
Starting from the end means dates that are treated as strings sort correctly. Ever find yourself with a directory full of files named (or prefixed/suffixed) with things like "mar-5-2019" or "12-apr-2020"? Not the most convenient results when you sort by name. Whether this is the reason for the yyyy-mm-dd standard I don't know, but it's a reason I like it. — Monica Cellio 7 days ago
Besides the nice lexicographic order you get by default with YYYY-mm-dd, the timestamps are often extended with hour, minute, seconds, milliseconds. By starting with the year , adding them is done in a consistent way (see this). — Alexei 7 days ago
ISO 8601 is intended to be "locale agnostic" and unambiguous, and this "biggest to smallest units" approach is IMO a good choice, with advantages already pointed by previous comments. It's an information exchange format, not a human friendly one (although it is friendly once you get used to it) — hkotsubo 7 days ago