Ne, eben nicht Locale
Doch (set-)locale. Das ist die variable Nutzereinstellung (nicht nur) für Zeitformate und hat mit "Spracheinstellung des Servers" eigentlich nichts zu tun. Es können am selben Server gleichzeitig (theoretisch unbegrenzt) viele Nutzersitzungen mit unterschiedlich gesetzten Lokalisierungseinstellungen ablaufen. Und sogar innerhalb dieser Nutzersitzung, sogar "per Thread" geändert werden. Letztendlich sind die via HTTP-Request auf einem Webserver ausgelösten Aktivitäten auch nichts anderes als Threads.
Ich wüsste nicht, warum ich auf diese bequeme Möglichkeit zur Formatierung insbesondere von Datumsangaben verzichten sollte.
Ich habe mal aus den Ausgaben von
<?php
$sprachen = explode( "\n", `locale -a` );
foreach ($sprachen as $s) {
if ( strpos ( $s, '.utf8' ) ) {
$sprache = str_replace( '.utf8', '.UTF-8', $s );
if ( $l = setlocale ( LC_ALL, $sprache ) ) {
echo $l . " :\t" . strftime ( '%x', strtotime( '-1 days' ) ) . "\n";
}
}
}
manuell ein paar krasse Fälle herausgesucht.
en_US.UTF-8 : 03/09/2018
it_IT.UTF-8 : 09/03/2018
tl_PH.UTF-8 : 03/09/18
uz_UZ.UTF-8 : 09/03/18
Will man sich die in verschiedenen Gegenden der Welt verständlichen Datumsformate selbst bauen müsste man dieses sonst auch noch quasi manuell übersetzen — sonst hat man womöglich am 3. September 15000 kreischende zwölf bis Vierzehnjährige nebst den anhängigen, stets terrorverdächtigen Hubschraubermüttern und oropaxtragenden, weit gereisten, völlig entnervten und also schwer gewaltbereiten Vätern vor dem Volkspalast obwohl das Konzert des Backfischhypnotiseurs schon am 9. März war.
Das will keiner haben, also mache ich es lieber richtig.