The original issue with dates calculated as decimal numbers was actually pretty serious. Because of that issue, I couldn’t trust formulas that would e.g. check on overlapping times for events, because oftentimes 4 AM + 1 hour wouldn’t be <= 5 AM, but calculate to 5:00:01 or something like that because of rounding issues.
Anything related to localization, though, is super tricky, as other commentators said. It’s especially tricky when you know how Coda handles formatted data — it stores it on the doc level, not user level. Hence column date format becomes universal for all users of the same doc. Localization would imply that each person would see their own version of the date, but it’s simply not technically possible yet. One interim solution would be allowing to select default date format for the doc (to automatically choose when creating new columns) akin to how one can select their default timezone for new docs. But knowing how Coda does features, I’m fairly sure they wouldn’t be happy to ship such a half-baked solution these days.
There’s a workaroundish way to approach user-specific date formats (albeit for display only) with user-specific settings and a FormatDateTime() formula with those specific values calculated at runtime (like here: PSA: You can have different users doing calculations with different values in the same rows). But yeah, it’s a workaround that uses a hidden formula, so not recommended really. I’d only do this if the client insisted they wanted this.