Conversion de dates à deux caractères en dates à quatre caractères
J'ai une application qui convertit automatiquement les dates non valides, avec seulement des années à deux caractères en un format de date valide pendant que l'utilisateur remplit le formulaire:
(REMARQUE: l'application est uniquement utilisée par des organisations britanniques, les dates sont donc uniquement au format britannique)
01/01/01 to 01/01/2001
14/05/58 to 14/05/1958
21/11/25 to 21/11/2025
Il détermine le siècle à utiliser sur la base d'un seuil semi-arbitraire sur 2050, donc si un utilisateur entre 49, ils obtiendront 2049, mais s'ils entrent 50 ils auront 1950.
La conversion se produit lorsque l'utilisateur tabule hors du champ et est immédiatement visible.
J'ai récemment reçu une plainte d'un utilisateur qui m'a dit qu'il était entré 10 et obtenu 2010, mais entré 27 et obtenu 2027, pas le 1927 ils espéraient. Leur raisonnement était que le 2027 était dans le futur et devrait donc être converti en 1927 à la place (car la date future était impossible).
Je pense qu'à long terme, j'aimerais simplement me débarrasser de cette fonctionnalité - je n'ai aucune idée de ce qui va se passer lorsque nous atteindrons 2050 ... Mais à court terme, est existe-t-il un moyen de modifier l'algorithme de base existant pour le rendre plus intuitif ou convivial?
Contexte (sans rapport avec la question)
Pour les personnes intéressées, l'utilisateur peut également choisir la date dans une liste de dates, ou entrer une date dans quelques autres formats avec divers tirets et barres obliques et le système fera des ajustements similaires. Si le système n'est pas en mesure d'ajuster le format de date valide, il alerte l'utilisateur via un signal visuel et la validation sur la page échoue.
Les utilisations des termes "valide" et "invalide" ici sont purement liées à la demande et n'ont aucune incidence sur un format de date national ou international particulier .
Similaire à cette question: subtilités du sélecteur de date: saisie de l'année à l'aide des touches numériques
Quel est le contexte de votre candidature? Le contexte compte vraiment pour les dates. Considérez les deux situations suivantes.
- Une application de budgétisation où les utilisateurs planifient leurs dépenses pour les années à venir
- Une inscription à la réunion universitaire où les utilisateurs entrent leur date d'obtention du diplôme
De toute évidence, si les gens sont planification, ils seraient ennuyés d'avoir une date dans le passé et si les gens entraient des dates qui ont arrivé ils seraient ennuyés d'avoir une date dans le avenir.
Je suggérerais de regarder les années que vos utilisateurs entrent dans leur ensemble et de voir si vous pouvez trouver des modèles. Vos utilisateurs peuvent s'attendre à saisir des dates allant jusqu'à dix ans dans le futur, mais aussi des dates bien antérieures. Dans un tel cas, vous souhaiterez peut-être modifier le seuil de "50" à "10 plus l'année en cours". Mais encore une fois, tout dépend du comportement de vos utilisateurs dans votre contexte particulier.
Comme Stephen l'a déjà dit: le but de la date entrée est très important.
J'ai récemment développé un widget d'entrée de date qui fait aussi cela (et plus). Il permet de saisir les dates dans pratiquement n'importe quel format. Lorsqu'il reconnaît les données saisies comme une date, il affiche une fenêtre contextuelle passive sous le widget avec les dates correspondantes possibles pour le texte saisi. L'ordre et la disponibilité des correspondances dépendent des paramètres régionaux des utilisateurs et des limites de date valides définies sur le widget. Ainsi, pour entrer une date de naissance, les dates valides ne sont que des dates du passé jusqu'au jour inclus, alors que pour prendre des rendez-vous, les dates valides seraient des dates futures, à partir d'aujourd'hui.
Cela fonctionne assez bien. Lorsque les utilisateurs entrent dans une année à deux chiffres, la date interprétée leur est présentée avant même avant de quitter le widget, et ils peuvent en sélectionner une autre que la date principale dans la liste de suggestions si nécessaire. Il est même possible de ne pas entrer du tout dans une année, tout en obtenant des suggestions valables. Cela est utile pour des choses comme les rendez-vous (un avenir proche est supposé être la suggestion la plus probable) ou pour des contextes comme les rapports de police (le passé proche est supposé pour l'année pour la suggestion la plus probable).
Tout d'abord, n'utilisez pas deux années de caractère. Nous avons fini avec les horreurs de l'an 2000, alors apprenons-en.
Ensuite, en supposant qu'il existe raison critique pour utiliser deux années de caractères: si vos utilisateurs n'entrent pas de dates futures, ou si ces dates futures sont liées à quelque chose près de la date actuelle (disons quelques années dans l'avenir), vous ne devez pas utiliser la méthode que vous utilisez maintenant.
Vous devez faire varier le seuil dans votre application de conversion de date vers une variante de la date actuelle.
Par exemple. seuil = année_courante + 5
Oui c'est possible. En utilisant un sélecteur de date GUI bien conçu. L'interface graphique résout toujours des problèmes comme celui-ci.