Mungkin ada beberapa dampak karena berbeda dalam urutan penyortiran, hubungan huruf besar-kecil, urutan susunan, pemisah ribuan, simbol mata uang default, dan lainnya.
C.utf8 =Lokal default sesuai standar POSIX. Hanya karakter ASCII ketat yang valid, diperluas untuk memungkinkan penggunaan dasar UTF-8
en_US.utf8 =Lokal UTF-8 Inggris Amerika.
Meskipun saya tidak yakin tentang efek spesifik yang mungkin Anda alami, namun saya yakin Anda dapat menyetel lokal dan enkode di dalam aplikasi Anda jika diperlukan.
Berikut adalah beberapa alasan mengapa saya menambahkan LC_TIME=C.UTF-8 di /etc/default/locale , seandainya itu membantu seseorang:
Ini memberikan jam 24 jam alih-alih AM/PM di Firefox untuk tipe input HTML5 =waktu (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time) dan menggunakan datepicker dalam format DD/MM/YYYY alih-alih MM/DD/YYYY untuk input HTML5 type=date (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date).
Ini memungkinkan untuk menggunakan format tanggal internasional YYYY-MM-DD (ISO 8601) dengan jam 24 jam saat membalas email di Thunberbird.
Sebelumnya, hal itu dimungkinkan dengan LC_TIME=en_DK.UTF-8 (http://kb.mozillazine.org/Date_display_format) tetapi saat ini ada bug dan berhenti bekerja (https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c155).
Sunting:Sekarang bahkan LC_TIME=C.UTF-8 solusi tidak berfungsi untuk Thunberbird (https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c197) tetapi setidaknya en_IE.UTF-8 menyediakan format tanggal Eropa DD/MM/YYYY, bukan MM/DD/YYYY.
Secara umum C adalah untuk komputer, en_US adalah untuk orang-orang di AS yang berbicara bahasa Inggris (dan orang lain yang menginginkan perilaku yang sama).
untuk komputer berarti string terkadang lebih terstandarisasi (tetapi masih dalam bahasa Inggris), sehingga keluaran suatu program dapat dibaca dari program lain. Dengan en_US , string dapat ditingkatkan, urutan abjad dapat ditingkatkan (mungkin dengan aturan baru aturan gaya Chicago, dll.). Jadi lebih ramah pengguna, tetapi mungkin kurang stabil. Catatan:lokal tidak hanya untuk terjemahan string, tetapi juga untuk pemeriksaan (urutan abjad, angka (mis. pemisah ribuan), mata uang (menurut saya aman untuk memprediksi bahwa $ dan 2 digit desimal akan tetap ada), bulan, hari dalam minggu , dll.
Dalam kasus Anda, ini hanyalah versi UTF-8 dari kedua lokal tersebut.
Secara umum seharusnya tidak masalah. Saya biasanya lebih suka en_US.UTF-8, tetapi biasanya tidak masalah, dan dalam kasus Anda (aplikasi server), itu hanya mengubah pesan log dan kesalahan (jika Anda menggunakan locale.setlocale() . Anda harus menangani lokal klien di dalam aplikasi Anda. Program yang membaca dari program lain harus menetapkan C sebelum membuka pipa, jadi seharusnya tidak terlalu penting.
Seperti yang Anda lihat, mungkin itu tidak masalah. Anda juga dapat menggunakan POSIX lokal, juga tentukan di Debian. Anda mendapatkan daftar lokal yang terinstal dengan locale -a .
Catatan:Pengoptimalan mikro akan meresepkan C /C.UTF-8 lokal:tidak ada terjemahan file (gettext ), dan aturan sederhana tentang susunan dan pemformatan angka, tetapi ini hanya dapat dilihat di sisi server.