notamment, si les champs retenus ne respecte pas ISO 8601 et sont de la forme — par exemple — JJ/MM/AA (oui, année sur 2 chiffres). Déjà que ça gère moyennement le déploiement au Québec ou aux USA qui mixent allègrement MM/JJ/AA et JJ/MM/AA (ah le passage au 12 janvier un 1er décembre suite à màj du serveur NTP /o\), ce pourquoi je préfère AAAA-MM-JJ qui respecte le principe de moindre surprise — ou étonnement ;-) après, on passe au bug Y10K mais ça donne plus de temps :D
bon, après il y aura la gestion de l'évaluation des dates de naissance (ou autres, comme date de début de contrat) nous ayant donné la joie de gérer des choses en 2038, 2039, 2040, 2041, 2042 dès le 1er janvier 2000 lorsque le choix (malencontreux) a été fait de conserver une date sur 2 chiffres pour réduire la saisie de 2 caractères... (ne rigolez pas, c'est encore le cas à pas mal d'endroit...).
même si à la base, 2038 a été identifié comme la fin de EPOCH en 32 bits, cela a révélé pas mal de soucis connexes... bon, après quand ce ne sont que les logs qui sont concernés, c'est un tout petit peu moins grave (sauf pour ceux qui exploitent les logs justement...).
[^] # Re: 32 bits
Posté par BAud (site web personnel) . En réponse au lien Des lignes de métro, tramway et RER de la RATP concernées par le bogue de 2038. Évalué à 5. Dernière modification le 10 décembre 2025 à 10:40.
les soucis envisageables sont plus divers ;-)
notamment, si les champs retenus ne respecte pas ISO 8601 et sont de la forme — par exemple — JJ/MM/AA (oui, année sur 2 chiffres). Déjà que ça gère moyennement le déploiement au Québec ou aux USA qui mixent allègrement MM/JJ/AA et JJ/MM/AA (ah le passage au 12 janvier un 1er décembre suite à màj du serveur NTP /o\), ce pourquoi je préfère AAAA-MM-JJ qui respecte le principe de moindre surprise — ou étonnement ;-) après, on passe au bug Y10K mais ça donne plus de temps :D
bon, après il y aura la gestion de l'évaluation des dates de naissance (ou autres, comme date de début de contrat) nous ayant donné la joie de gérer des choses en 2038, 2039, 2040, 2041, 2042 dès le 1er janvier 2000 lorsque le choix (malencontreux) a été fait de conserver une date sur 2 chiffres pour réduire la saisie de 2 caractères... (ne rigolez pas, c'est encore le cas à pas mal d'endroit...).
même si à la base, 2038 a été identifié comme la fin de EPOCH en 32 bits, cela a révélé pas mal de soucis connexes... bon, après quand ce ne sont que les logs qui sont concernés, c'est un tout petit peu moins grave (sauf pour ceux qui exploitent les logs justement...).