Il peut y avoir un certain impact car ils diffèrent dans les ordres de tri, les relations majuscules-minuscules, les ordres de classement, les séparateurs de milliers, le symbole monétaire par défaut et plus encore.
C.utf8 =paramètres régionaux par défaut conformes aux normes POSIX. Seuls les caractères ASCII stricts sont valides, étendus pour permettre l'utilisation de base de l'UTF-8
en_US.utf8 =paramètres régionaux anglais américain UTF-8.
Bien que je ne sois pas sûr de l'effet spécifique que vous pourriez rencontrer, mais je pense que vous pouvez définir les paramètres régionaux et l'encodage dans votre application si nécessaire.
Voici quelques raisons pour lesquelles j'ai ajouté LC_TIME=C.UTF-8 en /etc/default/locale , au cas où cela aiderait quelqu'un :
Il fournit une horloge de 24 heures au lieu de AM/PM dans Firefox pour l'entrée HTML5 type=time (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time) et utilise un datepicker au format JJ/MM/AAAA au lieu de MM/JJ/AAAA pour l'entrée HTML5 type=date (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date).
Il permet d'utiliser le format de date international AAAA-MM-JJ (ISO 8601) avec une horloge de 24 heures lors de la réponse aux e-mails dans Thunberbird.
Auparavant, c'était possible avec LC_TIME=en_DK.UTF-8 (http://kb.mozillazine.org/Date_display_format) mais il y a un bogue actuellement et il a cessé de fonctionner (https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c155).
Edit :Maintenant, même le LC_TIME=C.UTF-8 la solution de contournement ne fonctionne pas pour Thunberbird (https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c197) mais au moins en_IE.UTF-8 fournit le format de date européen JJ/MM/AAAA au lieu de MM/JJ/AAAA.
En général C est pour ordinateur, en_US est pour les personnes aux États-Unis qui parlent anglais (et d'autres personnes qui veulent le même comportement).
Le pour ordinateur signifie que les chaînes sont parfois plus standardisées (mais toujours en anglais), de sorte qu'une sortie d'un programme peut être lue à partir d'un autre programme. Avec en_US , les chaînes pourraient être améliorées, l'ordre alphabétique pourrait être amélioré (peut-être par de nouvelles règles de style de Chicago, etc.). Donc plus convivial, mais peut-être moins stable. Remarque :les paramètres régionaux ne sont pas uniquement destinés à la traduction des chaînes, mais également au classement (ordre alphabétique, nombres (par exemple, séparateur de milliers), devise (je pense qu'il est prudent de prédire que $ et 2 chiffres décimaux resteront), mois, jour de la semaine , etc.
Dans votre cas, il s'agit uniquement de la version UTF-8 des deux paramètres régionaux.
En général, cela ne devrait pas avoir d'importance. Je préfère généralement en_US.UTF-8, mais généralement cela n'a pas d'importance, et dans votre cas (application serveur), cela ne devrait changer que les messages de journal et d'erreur (si vous utilisez locale.setlocale() . Vous devez gérer les paramètres régionaux du client dans votre application. Les programmes qui lisent à partir d'autres programmes doivent définir C avant d'ouvrir le tuyau, cela ne devrait donc pas vraiment avoir d'importance.
Comme vous le voyez, cela n'a probablement pas d'importance. Vous pouvez également utiliser POSIX locale, également définie dans Debian. Vous obtenez la liste des locales installées avec locale -a .
Remarque :La micro-optimisation prescrira C /C.UTF-8 locale :pas de traduction des fichiers (gettext ), et des règles simples sur le classement et le formatage des nombres, mais cela ne devrait être visible que côté serveur.