Par exemple, après la mise à jour 4.9.5, mon site wordpress affiche cet horodatage dans les paramètres de fuseau horaire: 2018-04-05 (5 avril)
Mon site est défini sur Danois et au Danemark, le format de temps est jj/mm. Le format de date est correct, pourquoi ne génère-t-il pas le contraire dans le fuseau horaire?
Cela signifie que j'ai un formulaire où vous soumettez une date, mais il est inversé quand il est soumis. Si vous choisissez le 1er juillet, il publie ensuite le 07/01 au lieu du 01/07.
J'ai essayé de faire des recherches, mais je n'arrive pas à trouver la solution.
J'espère que vous pourrez aider.
Si c'est l'exemple dans les paramètres de fuseau horaire dont vous parlez ici:
Ensuite, ce comportement est attendu, et est correct par définition selon les normes ISO car ce n’est pas le moment, c’est un horodatage .
Ainsi, l'heure référencée n'est pas ambiguë et c'est le seul endroit dans WordPress où l'horodatage est utilisé dans l'interface utilisateur de l'administrateur. En tant que tel, il ne suit pas les paramètres de format de date ou de format d'heure, car il ne s'agit pas d'une date/heure formatée, mais d'un horodatage. Les horodatages ont des formats normalisés
Parce que les Américains ont insisté sur le MM/JJ/AAAA et que le reste du monde utilise le JJ/MM/AAAA, tout le monde s'est réuni en 1988 et il a été convenu que le format universel correct canonique était AAAA/MM/JJ aka ISO_8601 pour lequel il n'y avait aucune ambiguïté. Un certain nombre d'autres normes de date ont été remplacées en même temps
Comme c'est un horodatage, il faut ce format. Sauf si vous affichez des horodatages complets sur le frontend, c'est le seul endroit où il apparaîtra dans ce format
Pour plus d'informations, voir https://en.wikipedia.org/wiki/ISO_8601