JJ / MM / AA ou JJ / MM / AAAA?
Il y a eu des discussions sur l'ordre de DD, MM, YYYY, mais jamais vraiment aucune discussion sur la raison pour laquelle les concepteurs choisissent d'utiliser YYYY sur YY (par exemple, 01/01/2017 plutôt que 01/01/17).
Une idée pourquoi il y a une telle préférence?
Je peux brièvement penser à certains cas où l'inclusion de l'intégralité de YYYY est utile en fonction du contexte, mais en supposant que le système que je conçois ne traitera pas d'objets centenaires, je n'aurais pas besoin de l'intégralité de YYYY. Ai-je raison? N'est-ce pas bien d'utiliser simplement YY alors?
Il n'y a pas de bonne réponse universelle à cette question , mais il y a certainement deux avantages de YYYY:
- en montrant les deux nombres principaux que vous pouvez facilement dire, par exemple 1911 à partir de 2011,
- vous savez exactement où se situe l'année dans les cas où l'année se situe dans la plage XX01-XX12.
En d'autres termes:
Notation Possible interpretations:
----------- -------------------------
09/10/11 Four:
September 10th 2011
9th of October 2011
2009, 10th of November
2009, October 11th
09/10/2011 Two:
September 10th 2011
9th of October 2011
2009/10/11 Two as well:
2009, 10th of November
2009, October 11th
Donc, comme vous pouvez le voir, en indiquant à l'utilisateur où se situe l'année, vous limitez le problème. Si la date date d'une année qui se termine par un nombre supérieur à 31 (qui est le nombre le plus élevé possible dans les autres champs), quelque chose d'intéressant se produit:
Notation Possible interpretations:
----------- -------------------------
09/10/33 Two:
September 10th 2033
9th of October 2033
Cependant , l'interprétation ci-dessus nécessite que l'utilisateur analyse d'abord le contenu de la chaîne, ce qui augmente considérablement la charge cognitive. La réflexion serait:
"09 est-il l'année? Je ne sais pas. Celle du milieu n'est pas l'année. Oh, 33 est l'année. Donc 09 doit être le jour ou le mois."
Bien sûr, cela se produit en un clin d'œil (Eh bien, deux d'entre eux. Eh bien, trois), mais c'est toujours une charge cognitive et si les utilisateurs doivent faire face à beaucoup de dates sous cette forme, ils peuvent avoir besoin de passer par le même processus indésirable de recherche de l'année plusieurs fois jusqu'à ce qu'ils apprennent. Et ils ne devraient pas avoir à apprendre.
Et pour ceux-ci, vous n'avez pas besoin de vous soucier du contenu, vous pouvez facilement dire où l'année regarde simplement la chaîne obscurcie:
- ▓▓-▓▓-▓▓▓▓
- ▓▓/▓▓/▓▓▓▓
- ▓▓▓▓/▓▓/▓▓
- ▓▓▓▓-▓▓-▓▓
- ▓▓▓▓-▓▓
- ▓▓-▓▓▓▓
Le problème jour vs mois: approche graduelle versus culturelle
Maintenant, nous arrivons au vrai coupable pourquoi les dates ne sont pas si claires: mois contre jour. Disons que nous avons résolu notre problème avec l'année et que nous devons encore nous différencier ici: ▓▓/▓▓/▓▓▓▓
Notation Possible interpretations:
----------- -------------------------
09/10/2033 Two:
September 10th 2033
9th of October 2033
Pour moi, l'approche graduelle, où les unités de temps vont systématiquement du plus bas au plus élevé (donc: JJ/MM/AAAA) ou l'inverse (AAAA/MM/JJ) est beaucoup plus logique. Malheureusement, dans un système que les utilisateurs n'abordent que de temps en temps, peu importe si vous utilisez cette approche, car ils ne se souviendront pas que vous avez utilisé il.
D'autre part, le format MM/JJ/AAAA pour la date est courant aux États-Unis, au Canada, au Groenland, aux Philippines et dans plusieurs pays africains ( source ), comme abréviation de la façon dont la date est prononcé: "10 septembre 2017". Cependant, comme une autre prononciation est également autorisée, cela ne crée que de la confusion.
Pour sortir de cette folie, vous pouvez envisager de changer MM en version textuelle (par exemple raccourci: OCT/10/2017 ou 09/SEP/2017), mais dans ce cas, vous tombez dans un problème de traduction pour les utilisateurs internationaux.
Usage professionnel
Une situation où vous n'avez pas besoin de vous soucier de la notation est une situation où les utilisateurs traitent beaucoup avec les données de date, principalement de manière professionnelle. Deux exemples que je peux vous donner de ma tête seraient des analystes financiers (observant les changements sur le marché) ou des photographes traitant de nombreuses photos nommées en utilisant une convention qu'ils connaissent par cœur. S'ils le savent par cœur, ce n'est pas un problème.
Ancre de contexte "Now"
Une autre situation où l'importance de ce qui est l'année dans la date devient moins importante est lorsque les utilisateurs sont plus orientés vers "maintenant". Facebook en est un bon exemple.
Gain d'espace
L'économie d'espace peut parfois être un facteur très important pour prendre des décisions. Encore une fois, dans les tableaux de bord contenant de nombreuses données, l'année peut être soit complètement obsolète, soit être tronquée. Mais je crois que ces tableaux de bord tombent dans le panier de l'utilisation professionnelle la plupart du temps, donc pas besoin de trop s'en soucier.
Combinaison en une seule chaîne de texte et tri
Dans certains cas, vous pouvez être confronté à une situation où vous devez combiner la date en un seul gros morceau de texte. Par exemple, la convention de dénomination que j'utilise pour les fichiers photo est YYYYMMDD_HHmmSS.ext, (par exemple. 20170911_113426.RAF) Ceci, encore une fois, tombe dans le panier d'utilisation "pro"; Cependant, il fournit également des moyens de trier par date sans avoir à craindre que l'attribut de date d'un fichier change (par exemple, car il a été déplacé vers un système de fichiers qui ne prend pas en charge ce type d'attribut, ou modifié dans une application qui le supprimerait). ). Ce scénario d'utilisation apporte deux conclusions:
- c'est bien d'avoir une année complète, car au moins les photos de 2000 seront après celles de 1999,
- il est bon d'utiliser l'ordre progressif, passant de l'unité supérieure à l'unité inférieure.
Emballer:
Vos utilisateurs connaissent-ils le système par cœur? Utilisent-ils quotidiennement l'attribut date? Si c'est le cas, ne vous souciez pas de la reconnaissance de l'année, mais considérez des éléments supplémentaires tels que la triabilité ou l'unicité (par exemple, 1911 à partir de 2011 lorsque la portée de la date est large.)
Vos utilisateurs n'abordent-ils l'attribut date qu'occasionnellement? Si c'est le cas, fournissez une reconnaissance plus élevée de ce qui est quoi dans la date sans charge cognitive élevée de leur côté: augmentez l'année à quatre chiffres, indiquez clairement où se trouve le mois. À moins que l'espace ne soit critique pour vous, auquel cas vous devez vous préparer aux compromis.
ÉDITER:
Comme de nombreux commentaires ci-dessous se réfèrent à la norme ISO-8601, je voudrais expliquer pourquoi je ne l'ai pas ajouté dans ma réponse d'origine.
Je crois que le mot "standard" a une double signification: une norme et une convention.
A une convention est une approche courante de quelque chose qui est utilisé par un groupe limité de personnes. En ce qui concerne un sujet spécifique comme celui-ci, il peut y avoir (et il y a généralement) diverses conventions, dont l'une peut contredire une autre (encore une fois: comme dans ce cas). De plus, la plupart des conventions contredisent la norme et la norme contredit la plupart des conventions.
Les conventions ont leurs racines historiques, linguistiques, pratiques, etc. Dans le cas des conventions de date, par exemple le MM/DD/YY vient de la manière américaine de dire la date comme "5 novembre 2008" alors qu'ailleurs cela peut être différent.
Passons maintenant à norm.
A norm a pour rôle de refuser la plupart des conventions utilisées jusqu'à présent, pour remplacer la plupart d'entre elles. Il peut s'agir de l'une des conventions qui a été choisie comme norme, mais la plupart des conventions doivent être refusées si une seule doit rester. Une norme est généralement bien pensée. La norme dans ce cas particulier a beaucoup de sens, car chaque unité suivante est plus petite que la précédente (et cela permet une comparaison plus facile entre les dates, le tri par date sous forme de chaîne de texte, etc.).
Il y a certainement deux façons d'aller d'ici.
L'une consiste à pousser la norme jusqu'à ce qu'elle soit utilisée partout, ce qui assurera à long terme la cohérence de la norme utilisée partout dans le monde. Obliger les gens à utiliser quelque chose de différent de ce qu'ils ont toujours utilisé a ses inconvénients, et cette manière est - dans une certaine mesure - contre l'utilisabilité.
L'autre option est de s'adapter aux conventions locales que les gens comprennent. Ayant dérivé de raisons culturelles, linguistiques, pratiques, les conventions se sentent localement plus adéquates. Mais en même temps, lorsque les personnes utilisant une convention rencontrent également les autres lors de la navigation sur le Web, elles peuvent devenir confuses lorsqu'elles voient quelque chose de différent de ce à quoi elles étaient habituées, et saluer cette approche est également - dans une certaine mesure - contraire à l'utilisabilité.
De cette façon, je crois toujours qu'il n'y a pas de réponse universellement bonne à cette question, et elle pourrait ne pas apparaître de sitôt. Ce qui peut être fait pour l'instant, c'est de limiter certains éléments de confusion - comme dans le cas où l'année est écrite en quatre, pas en deux chiffres.
En règle générale, il est jamais OK pour utiliser une année à 2 chiffres. Si vous pouvez prouver que l'utilisation d'une année à 4 chiffres entraînera la mort horrible de milliers de bébés et de mignons lapins moelleux, cela pourrait être une exception à la règle, mais probablement pas.
J'ai vu des centaines d'échecs de processus coûteux simplement parce qu'un programmeur pensait qu'il était parfaitement correct d'utiliser une année à 2 chiffres ou un idiome de date local cette fois .
Mais je n'ai jamais vu un programme ou un processus échouer en raison du choix de AAAA-MM-JJ ISO 8601 Formatage de date standard . C'est toujours le bon choix. Prenez ce conseil à cœur et vous ne le regretterez jamais.
Le formulaire standard YYYY-MM-DD est également compréhensible pour les personnes de n'importe quel pays, de tout âge - même ceux qui sont nés dans des pays où le format traditionnel est quelque chose d'objectivement braindead, comme MM/DD/YY ou DD/YY-MM. Il trie également correctement sans reformater, une fonctionnalité bonus!
Prenons cet exemple: 1/02/07.
À première vue, cela pourrait être n'importe quoi. Maintenant, faisons-le AAAA: 1/02/2007.
Un peu de différence, non? C'est l'une des principales raisons du format YYYY. Très peu de points de données sont au format à 2 chiffres/2 chiffres/4 chiffres , ce qui évite un peu de confusion.
Lorsque vous ne traitez pas d'événements centenaires, il sera parfaitement logique d'utiliser YY au lieu de YYYY.
Même Stackexchange suit le même schéma:
"a demandé le 6 janvier 2009"
MM/DD ou DD/MM change en fonction du continent , mais le YY ou YYYY reste le même pour le monde entier (au moins dans les pays qui utilisent l'anglais comme langue officielle).
ISO 2014 , bien que remplacée, est la norme qui a initialement introduit la notation de date entièrement numérique dans le plus au moins- ordre significatif [AAAA] - [MM] - [JJ] . Le système de numérotation hebdomadaire ISO a été introduit dans ISO 2015, et l'identification des jours par dates ordinales a été initialement définie dans ISO 2711.
Représentations tronquées
ISO 8601: 2000 a permis la troncature (par accord), où les principaux composants d'une date ou d'une heure sont omis. Cela a notamment permis d'utiliser des années à deux chiffres et les formats ambigus YY-MM-DD et YYMMDD . Cette disposition a été supprimée dans l'ISO 8601: 2004.
Depuis MS Window 10:
Les options YY sont entièrement valides
Je pensais que l'argument concernant aaaa plutôt que aa avait été traité à l'approche de l'an 2000? Il y a presque certainement des gens qui lisent ceci qui seront vivants pour voir 2099 passer à 2100, et il y a presque certainement des codeurs qui n'ont pas appris la leçon dont le code ira horriblement en forme de poire en 2100 (quand il sera toujours utilisé par quelqu'un, quelque part).
De plus, les gens vivent au-delà de leur 100e anniversaire en nombre toujours croissant. Supposer qu'une date de naissance entrée par l'utilisateur est toujours inférieure à cent ans est probablement une très mauvaise hypothèse dans un avenir proche. J'ai déjà lu des lettres adressées aux parents de retraités de 104 ans concernant le choix de leur première école - les menaces juridiques concernant la non-fréquentation de ces retraités à l'école primaire ne manqueront pas de suivre!
Compte tenu du fait que cette question a été posée dans la section UX de stackexchange, je suppose que la réponse devrait se concentrer sur les attentes de l'utilisateur.
J'ai personnellement travaillé dans un grand projet de l'an 2000, et je m'attendrais à ce que les développeurs de logiciels aient tiré la leçon de ces projets. Cependant, il semble toujours y avoir un certain désaccord sur la nature de cette leçon. Ce n'est pas que les années à 2 chiffres sont toujours mauvaises.
C'est une idée fausse historique que la principale raison du stockage des valeurs de l'année sur 2 chiffres était d'économiser la mémoire de stockage. La vérité est que les utilisateurs voulaient des années à 2 chiffres dans leur interface principalement parce qu'ils ne voulaient pas entrer de données inutiles. La faute des développeurs n'était pas de différencier entre les données de l'interface utilisateur et les données stockées. Il aurait été parfaitement acceptable d'utiliser des années à 2 chiffres dans l'interface utilisateur, à condition qu'elles soient stockées sur 4 chiffres. Si c'était le cas, toute ambiguïté aurait été détectée instantanément au lieu d'années plus tard.
En conséquence, en ce qui concerne l'UX, je répondrais que il est parfaitement acceptable d'utiliser des années à 2 chiffres dans l'interface utilisateur, tant que
- il n'est pas ambigu dans le contexte donné
- il est toujours stocké en tant que valeur à 4 chiffres
Pour illustrer un "contexte donné":
- une date de vol sur un site de réservation fonctionne bien avec une année à 2 chiffres, car l'utilisateur ne pourra jamais réserver une date de vol supérieure à 100 ans dans le futur
- une date d'anniversaire ne fonctionnera presque jamais bien avec une année à deux chiffres, car au moins certaines personnes vieillissent de plus de 100 ans
L'utilisation de YYYY sur YY garantit qu'il est immédiatement évident lequel des trois champs représente l'année. Cela résout une certaine ambiguïté, non seulement entre différents siècles, mais aussi entre les formats de date. Cependant, JJ/MM/AAAA est rarement une représentation acceptable.
À des fins d'affichage, vous pouvez utiliser un format long, par exemple: `` mardi 4 avril 2017 ''. Il est clair et sans ambiguïté, mais prend une place importante et variable et peut nécessiter une traduction dans d'autres langues.
Pour les représentations numériques, utilisez toujours AAAA-MM-JJ ( ISO 8601 ), qui est garanti sans ambiguïté, est une norme ISO, est facile à analyser par les ordinateurs et les humains (même ceux habitués à d'autres formats), ne nécessite aucune localisation et peut être ordonné chronologiquement par tri lexical.
Avantages de YY:
- Économise 2 lettres d'espace
- Économise 0,2 seconde de temps lors de la saisie de la date.
Inconvénients de YY
- Vous oblige à utiliser différents formats de date dans le même produit (vous devez utiliser YYYY dans certains cas, à un moment donné)
- Ajoute de l'ambiguïté (quel siècle?)
- Ajoute une ambiguïté (laquelle est l'année et laquelle le mois?)
- Ajoute une ambiguïté (laquelle est l'année et laquelle le jour?)
- La lecture prend 0,2 seconde de plus (en raison de l'ambiguïté)
- Augmente le risque d'erreur utilisateur (pire vérification des entrées et en raison de l'ambiguïté)
- Augmente le risque d'erreurs de programmation (impliquant généralement le tri)
Vous devriez peser les avantages et les inconvénients les uns par rapport aux autres en fonction de votre cas d'utilisation - la sauvegarde de ces 2 lettres est soudainement importante si la meilleure alternative suivante est le défilement sur un écran LED. Économiser 0,2 seconde de saisie peut être très utile dans un flux de travail qui nécessite qu'un utilisateur saisisse 1 000 dates par jour. Mais dans presque tous les autres cas, l'équilibre s'incline dans l'autre sens.
Le passage à l'an 2000 a créé beaucoup de travail, ce qui était bien d'un point de vue monétaire - mais c'était vraiment ennuyeux travail. Je ne vivrai pas pour voir 2100, mais ne rendez pas la vie ennuyeuse à nos héritiers ...
(Pas assez clair? De ~ 1985 à 1999, nous passons tous de nombreuses heures de travail à mettre à niveau des systèmes où les développeurs qui manquaient de prévoyance avaient utilisé des dates à 2 chiffres. Veuillez ne pas répéter cette erreur.)
La plupart des gens utilisent le format JJ/MM/AAAA. Le format de la région/du pays varie. Format de date par pays
Pour les horodatages, dans les noms de fichiers ou de répertoires, j'utilise toujours YYYYmmdd de cette façon, le tri lexical normal (par exemple ls -l command) répertorie toujours les éléments dans la séquence correcte. Ni mmddYYYY ni ddmmYYYY n'ont cette propriété.
Dans les notes manuscrites, j'utilise parfois juste YYmmdd pour plus de commodité et quand je ne confondrai pas le siècle.
Bien sûr, en l'an 9999, cette notation causera encore une fois beaucoup d'angoisse.
Cela dépend de ce que vous essayez de réaliser. Dans certains cas (peut-être plus que vous ne le pensez), les utilisateurs peuvent avoir besoin de voir une année à quatre chiffres, tandis que dans d'autres, une année à deux chiffres est adéquate. Ce ne sont pas seulement les événements centenaires que vous devez prendre en compte, et cela dépend de la façon dont vous attendez de vos utilisateurs qu'ils saisissent les dates. Voici quelques exemples:
- Date de naissance: 1999 vient avant 2000, mais 99 trierait après 00, donc pour une date de naissance dans quelque chose comme une liste déroulante, une année à 4 chiffres est logique (affichant 2 chiffres mais triant par 4 est faisable, mais peut être déroutant pour l'utilisateur).
- Calendar app: L'interface de Google Calendar n'est pas idéale pour cela, mais je peux ajouter des événements avant l'époque POSIX - donc si j'avais des agendas des années 60, je pourrais les numériser dans google (ce serait un mauvaise idée, d'ailleurs je ne serais pas né alors). Alternativement, je pourrais probablement l'utiliser pour planifier un nouvel ensemble au 23e siècle. Si vous construisez quelque chose à usage général, vos utilisateurs en trouveront plus d'utilisations que vous n'auriez jamais pu .
Un peu d'opinion: cette clarté/flexibilité bat l'économie d'espace.
D'un autre côté, il est possible de travailler dans des délais beaucoup plus restreints. Si vous vendez des billets de théâtre et que les événements ne peuvent avoir lieu que dans l'année à venir, les utilisateurs n'ont qu'à voir une année à deux chiffres. Même les commandes passées auraient un sens complet avec seulement YY dans ce cas.
Avant d'écrire mon point de vue, je dois dire que c'était une excellente réponse de @Dominik Oslizlo!
Ok, pour le format de l'année, je pense que cela dépend totalement des éléments suivants:
- Audience (Leur région géographique) - Les utilisateurs des pays asiatiques préfèrent dire la date en premier, puis spécifier le mois. C'est l'opposé pour l'Amérique du Nord ou les pays occidentaux. Par exemple, le 11 septembre est la façon américaine de dire la date alors qu'en Inde, c'est le 26 novembre. Maintenant, c'est un exemple intéressant car les deux dates sont associées à des attaques terroristes. 9/11 (11 septembre), le monde est au courant et 26/11 (26 novembre) pour les attentats de Mumbai. La façon dont il est référé est perceptible. Cela reflète la culture.
Donc, il y a déjà des chances de confondre la date et le mois, l'année est mieux mentionnée complète (AAAA)
- But (Si le but de demander la date et l'année pour établir un événement s'est produit récemment ou est-ce une date de naissance) Imaginez un cas d'anniversaire. Existe-t-il un moyen de vérifier que l'utilisateur est né en 19yy ou 20yy s'il est mentionné uniquement au format yy?.
Conclusion:
Pour éviter toute ambiguïté, suivez le format DDMMYYYY. Il soutient la façon dont nous référons l'année dans notre vie quotidienne. La tendance est de dire 20 17 ou 2k17 ou autre, mais son format YYYY complet.
Alors, soutenez la façon dont les utilisateurs pensent. Par conséquent, YYYY serait toujours clair!
Honnêtement, en ce qui concerne les dates, j'utilise toujours la représentation à 3 chiffres du mois, juste parce que les Américains ...
Comme beaucoup l'ont souligné, le 09/10/11 pourrait être le 9 octobre ou le 10 septembre, alors que si vous avez le 09/11/11, tous les utilisateurs savent ce que vous recherchez.
Soit cela, soit un moyen (évident) pour l'utilisateur de savoir quels sont les champs (par exemple, mettre le format "au format (jj/mm/aa)" dans la question ou utiliser un texte d'espace réservé dans les entrées)
En ce qui concerne les années, l'utilisation de yy est beaucoup plus facile pour les utilisateurs, mais cela dépend de la raison pour laquelle vous l'utilisez. S'il s'agit d'un formulaire médical, il n'est pas impossible d'avoir une personne née dans les années 1920 qui remplirait le formulaire. Donc, dans quelques années, votre formulaire peut être très déroutant lorsque vous avez un bébé apparent remplissant un formulaire nécessitant un remplacement de la hanche.