par PresleyJesus
Depuis la nuit des temps, la gestion des dates est un véritable cauchemar en programmation. La manipulation des valeurs de date est souvent la cause des anomalies et des problèmes sur des systèmes en production.
Le risque est là quand on la manipule en chaîne de caractère (en string). Elle peut avoir n’importe quel format à ce moment-là. Aussi, les paramètres régionaux ou de localisation de l’environnement d’exécution peuvent la faire varier.
Pièges à dates
Voici une série d’endroits où l’on peut se faire prendre au piège avec une valeur de date erronée.
- Lecture d’un fichier plat (texte) ou d’un XML avec des dates écrites textuellement
- Saisie de date dans un champ texte
- Passages de données entre des couches applicatives (ex: un script Javascript envoie une date (format texte) dans un appel AJAX vers le serveur).
Trucs pour réduire les maux de tête
Vous pouvez réduire les ennuis en utilisant au maximum les classes de gestion de date natives au langage de programmation que vous utilisez. Ces fonctionnalités sont disponibles dans tous les langages modernes.
- Utilisez des composantes visuelles pour la saisie d’une date (ex. : DatePicker) qui retourne la date dans un format natif valide et insensible au format régional. En PHP, vous pouvez utiliser des Frameworks qui peuvent générer des champs de formulaire typés avec des champs date. En prime vous offrez un beau calendrier pour votre utilisateur.
- Valider à outrance la date texte avant de la convertir. Incluez dans votre message d’erreur le texte que vous avez tenté de lire (ça l’aide pour le soutien aux utilisateurs). Tout peut arriver!
- Dès que vous lisez une date texte, placez-la tout de suite dans une variable typée pour les dates.
- Quand vous devez écrire une date en format texte (sortie à l’écran, écriture dans un fichier), évitez d’utiliser les formats prédéfinis par les paramètres régionaux (ex.: short date).
Est-ce que les dates vous ont déjà hanté dans vos projets?
Pour ma part j’aime bien utiliser les timestamps unix pour la gestion des dates. Un bon vieux nombre entier de trimbale toujours plus facilement qu’une chaine de caractères entre diverses applications.
Qu’en penses-tu?
Pleinement d’accord. L’important c’est de jamais conserver la date en format texte. Est-ce que ça cause des problèmes avec les dates avant 1970, par exemple les date de naissances? Mais, le problème avec le Unix Time c’est à partir de l’an 2038 si il est conservé sur 32 bits. Il vont surement juste augmenter au jour pour pallier à ça. Voir: http://en.wikipedia.org/wiki/Year_2038_problem
Pour les dates de naissances inférieures à Epoch je crois que ça diffère selon l’implémentation. Certaines fonctions (comme strtotime() en PHP) offrent des workaround. J’admets que la solution n’est pas parfaite… J’ai bien hâte de voir les solutions qui seront proposés pour d’ici 2038
C’est poshe, mais il n’y a pas de solutions miracle, bien qu’il y ait des outils/techniques pratique.
Pour les dates de naissances (ou toute autre dates qui risque d’être inférieur à 1970, je n’ai pas vraiment le choix d’utiliser autre chose qu’un timestamp. Si c’est en DB, je vais prendre le type Date du SGBD, bien que ce qui me fait *%&*% c’est que ya pas un SGBD qui utilise le même format de date.
J’essaye d’utiliser un objet «Date» pour manipuler. C’est plus facile ensuite d’appeler des fonctions style «getDay()» , «getMonth()», «getYear()», «getDateInUSFormat()», «getDateInTimeStamp()», etc…
Et au niveau du SGBD, ce que je fait, c’est que ma couche qui gènére mes requètes SQL s’occupe de transformer mon objet Date vers le format requis par le SGBD (oui j’utilise des objets d’abstraction home-made qui me permet de générer mes requètes sans avoir à écrire du SQL directement dans le code, ce qui devient intéressant pour suporter les différent SGBD et améliorer la lisibilité du code).
Les dates sont et seront toujours le claver des informaticiens.
Il faut en prendre grand soin. J’ai fait souvent d’importation/exportation de données. Et j’ai passé des heures a valider les dates, a les ramener d’un format standard.
Tu as raison Nicolas, il faut rapidement les convertir en date à la lecture. Et utilisé, le plus possible des moyens pour éviter que les dates soient saisis ou stockés en string.
Aujourd’hui tout framework qui se respecte offre les fonctions ou les librairies nécessaires pour manipuler et convertir les dates, il serait qu’on de s’en passer..!
p.s. Jean-Michel, mois c’est 2050 que je suis currieux de voir .. fenestration des dates de l’an 2000.