Closed eliot-akira closed 7 months ago
@BenTangible @GabrielGallagher @juliacanzani
In commit 405fbf5, I've overhauled how ACF date field types are formatted.
Now they all get the default format from ACF field setting for "return value". Date format from Settings -> General -> Date Format is no longer taken into consideration.
A disadvantage is that the user must now specify the desired format for every Date field in its settings, instead of changing the default format all at once from site settings. This change also breaks backward compatibility, though from our recent discussion I think some of it was not working correctly anyway.
To summarize the changes:
Y-m-d
-> From site settings -> From field settings (default d/m/Y
)Y-m-d H:i:s
-> From field settings (default d/m/Y g:i a
)H:i:s
-> From field settings (default g:i a
)There's a reason why the original formats were the way they were (basically ISO 8601), because ACF's date formatting makes the value ambiguous (for example d/m/Y
versus m/d/Y
, or Ymd
versus UNIX timestamp), especially when combined with our own date formatting. The new logic gets the raw value from ACF and applies default formatting based on field settings, with all formatting handled by our Date module.
I've tested permutations of the above fields with and without format
and locale
attributes, but I'd appreciate it if you can confirm that the new behavior is correct - and that it's what we want in terms of ease of use and intuitiveness.
Tested the different permutations on my end and it all works as I'd expect.
ACF's date formatting makes the value ambiguous
HARD agree, haha! #Y-m-dMasterRace
Ultimately this is just an ACF failure and L&L should respect it. The real solution is that the default return format in ACF should be "use site date format."
Thanks for confirming the new change, it will ship in version 4.1.0
.
From #70
This will break backward compatibility, but it seems logical that ACF field setting has higher priority than site settings.