Foundation Locale.current is incorrect

Server Docker
1

I'm writing a server app with swift and deploying with podman (basically a drop-in replacement for docker).

I've noticed that, for timestamps to render correctly in html output, I need to set the container's timezone. Easy enough, and it works. Timestamps come out at the correct time by default.

However, I'm in the US and we do dates the stupid way, MM-DD-YYYY, while the default in linux/swift/not sure where it's actually coming from is DD-MM-YYYY, which is honestly far more logical, but my dumb redneck monkey brain is too used to our stupid way.

I've updated the container's locale's to en_US by running update-locale LANG=en_US.UTF-8 LANGUAGE=en_US:en LC_ALL=en_US.UTF-8 and setting export LANG=en_US.UTF-8 LANGUAGE=en_US:en LC_ALL=en_US.UTF-8 and can confirm the values have updated in the system settings (cat /etc/defaults/locale and locale reflect these values properly), but when using DateFormatter inside swift it insists on using the DD-MM-YYYY formatting, unless I explicitly set the instance's .locale to Locale(identifier: "en_US") in which case it finally formats it as MM-DD-YYYY. .current and .autoupdatingCurrent both remain at the default en_001.

Am I setting the wrong system locale setting to get that to propagate? Or perhaps reading from the system isn't yet implemented? I couldn't find any notes to that effect, but glancing at the foundation code, I see a couple hardcoded values for en_001, which might imply that it's currently completely hardcoded.... But I didn't thoroughly parse the code to understand what it's doing.

2

CC @Tony_Parker

3

On Darwin, the values for current and autoupdatingCurrent (which is just a pointer to current) depend on the results of user defaults. We don't have a user defaults replacement on Linux at this time, and the fallback on all platforms, including Darwin, is en_001.

It may be reasonable to have Linux check the environment variable as a step before the fallback, but that is indeed unimplemented. The missing part there is writing something that translates those into the equivalent ones we grab from defaults on Darwin (e.g., preferred numbering system, region, language, etc). In the meantime, as you discovered, you can indeed specify a Locale directly instead.

1 Like