Existe-t-il un format de date universel que tout le monde puisse comprendre?

10

Au Canada, tout le monde connaît le format de la date YYYY-MM-DD. En Europe ou en Afrique du Sud, ils préfèrent DD-MM-YYYY. Il y a des utilisateurs d'Afrique du Sud qui se confondent avec le YYYY-MM-DDformat de date. Existe-t-il un moyen de gérer cette situation?

Je pensais utiliser le format de méthode suivant pour tous: Feb 02, 2011

websites date-format formatting standards ambiguity Thierry Lam
la source
21
Je pense que le format AAAA-MM-JJ est également une norme ISO.
FrustratedWithFormsDesigner
2
"En Europe ou en Afrique du Sud, ils préfèrent DD-MM-YYYY." Sauf par exemple en Hongrie ( YYYY.MM.DD) ou en Finlande ( DD.MM.YYYY), ou ... Désolé, la réalité est en désordre :-(
Péter Török
6
Qu'en est-il des différents calendriers?
4
Lors de la collecte des données radar (en Amérique du Nord), nous avons utilisé cela pour les noms de fichiers: prefix_1999_12_23_16_45_53.ext. Raison principale: c'était sacrément facile à trier, à RECHERCHER et à analyser. Lors de la recherche, vous voulez vraiment commencer par l'unité la plus importante en premier afin d'atteindre l'objectif le plus tôt possible. Ce type de chaîne est même compatible avec les arbres binaires. Le laboratoire était dominé par des étudiants européens, mais je pense que c'était du bon sens, sinon une norme scientifique. Cependant, dans un pays où j'ai grandi, nous utilisions DD-MM-YYYY pour un usage quotidien. Raisonnement: à votre réveil, quelle est la première partie que vous souhaitez savoir?
Job
2
@Frustré, je suppose que son argument est qu'il existe des calendriers avec une année de départ différente (comment un musulman interpréterait-il par exemple le 30.12.1268?), Ou des mois de lune (dont il y a environ 13 par an), etc. Donc, pour être vraiment universel est plus que simplement s'entendre sur quel numéro est le jour et quel est le mois ...
Péter Török

Réponses:

15

La partie ambiguë est de différencier le jour du mois s'ils sont représentés par des nombres.

Est-ce que 02/03 signifie 03 février ou 02 mars?

En changeant l'identifiant du mois de son numéro par son nom, vous supprimez cette ambiguïté. Pour répondre à votre question, votre variante de Feb 02, 2011semble être une bonne solution.

Il y a toujours un problème potentiel avec le numéro de l'année si vous l'écrivez avec seulement 2 chiffres, mais alors c'est facile à résoudre (utilisez 4).


la source
10
Et puis, vous pouvez simplement avoir un fichier de traduction pour les noms de mois dans différentes langues.
FrustratedWithFormsDesigner
1
@FrustratedWithFormsDesigner Et n'oubliez pas d'obtenir également une traduction professionnelle des abréviations correctes (bien connues).
Nicole
Et les langues qui ne prennent pas la peine de nommer les mois?
JUSTE MON AVIS correct
19

Non. Il n'y a pas de format de date universellement reconnu.

ISO 8601 Définit une norme internationale pour les formats de date. En tant que tel, c'est probablement le meilleur compromis. Mais comme vous le dites, les utilisateurs n'aiment pas toujours ce format.

La seule solution correcte est de présenter un format différent pour différents pays. Vous pouvez constater qu'il existe une bibliothèque standard pour y parvenir si le langage de programmation que vous avez choisi a un nombre important d'abonnés.

Kramii
la source
2
C'est bien. J'utilise habituellement YYYYMMDD pour les fichiers journaux, etc. Maintenant, je peux dire que je suis simplement conforme à la norme ISO-8601!
Mark Harrison
1
Lorsque j'utilise ISO 8601, je trouve généralement qu'il est préférable de formater l'intégralité de la chose, c'est-à-dire 1999-12-25T00: 00: 00.000Z . Oui, cela ressemble à du charabia pour la personne moyenne, mais il n'y a aucune chance d'ambiguïté.
MattDavey
2
"La seule solution correcte est de présenter un format différent pour différents pays." - et comment, exactement, devrais-je imprimer une date sur un bon de livraison qui pourrait être expédiée partout dans le monde?
Scott Whitlock
@ScottWhitlock: Malheureusement, il n'y a pas de solution universellement acceptée à ce problème. Si vous ne savez pas où un colis est envoyé lorsque vous imprimez la date, alors ISO 8601 pourrait bien être votre meilleur choix.
Kramii
"La seule solution correcte est de présenter un format différent pour différents pays." Je dirais que ce n'est pas correct. Il se trouve que certaines bibliothèques ont une idée utile de mon format de date préféré, basé sur ma langue préférée, a provoqué une confusion. Mais comme première étape, car nous ne pouvons pas résoudre toutes les cultures en ce moment, soit utiliser ISO 8601 ou du texte pendant des mois ou quelque chose.
Erik I
9

Vous devez utiliser les informations culturelles pour cela. Ou au moins le format d'affichage local.

En JavaScript, vous pouvez utiliser la méthode toLocaleString pour la classe Date .

Pour C #, vous pouvez utiliser la chaîne de format lors de l'utilisation de ToString .

Une recherche rapide sur Google devrait vous montrer comment utiliser la culture dans la langue de votre choix.

Tyanna
la source
5

J'irais avec AAAA-MM-JJ (et j'écrirais toujours les années à quatre chiffres et les mois et les jours à deux chiffres). YYYY-DD-MM, à ma connaissance, est rare à rare, donc le format YYYY-MM-DD est celui avec le moins d'ambiguïté, et vos utilisateurs finiront par comprendre. De plus, vous bénéficiez de l'avantage du tri trivial.

jprete
la source
2

Pouvez-vous donner à chaque utilisateur ses propres paramètres régionaux, qui affichent ensuite les dates et autres informations en fonction de leurs préférences locales?


la source
1

Plusieurs fois, vous pouvez configurer les paramètres régionaux et utiliser I18n dans la plupart des cadres.

chiurox
la source
0

Dans le cas général, vous devrez spécifier à la fois le format et la valeur. C'est le seul moyen d'éviter toute confusion. Par exemple, vous pouvez dire "2011-02-02 (YYYY-MM-DD)". Cela se fait au détriment de la simplicité et de la lisibilité, alors connaissez votre public.

Vous pouvez, bien sûr, dire "Ci-après, toutes les dates sont au format AAAA-MM-JJ ...." Ensuite, "2011-02-02" apparaissant plus tard sera sans ambiguïté. Cela peut être plus agréable au goût, mais encore une fois, connaissez votre public.

yfeldblum
la source
À droite, sauf qu'en jour estonien = päev et mois = kuu, en philippin ce sont: araw et buwan, en finnois: päivä, kuukausi, en hongrois: sieste, hónap, en indonésien: hari, bulan, en maltais: saut, xahar , en roumain: zi, lună, en turc: gün, ay, en vietnamien: ngày, tháng ... sans parler de nombreuses langues où le mois ne commence pas par m ou le jour ne commence pas par d (allemand: Monat, Tag ) ainsi que les langues qui n'utilisent rien comme l'alphabet latin.
Job
1
Eh bien, "2011-02-02" est sans ambiguïté en tout cas ...;)
Martin
0

Cette suggestion est probablement inutile, mais j'ai vu des mois écrits en chiffres romains. Bien sûr, le 3 / XI / 2011 peut être le 11 novembre ou le 3 mars, mais je suppose que la première interprétation est plus naturelle.

ggambett
la source
1
Chiffres romains? "Naturel?"
Wonko the Sane
@Wonko, "naturel" dans le sens où, dans ce contexte, XI est plus susceptible d'être interprété comme un mois que comme un jour. J'avoue que c'est extrêmement subjectif.
ggambett
+1, je pensais à quelque chose comme ça moi-même. pourtant, je suis également d'accord avec vos critiques.
Job
N'ayant jamais, jamais vu ce format, je penserais d'abord «faute de frappe» ou «erreur de traduction» avant qu'il ne me vienne à l'esprit «chiffres romains». C'est seulement alors que j'essaierais de deviner le sens.
Wonko the Sane
Sans oublier que le 3 / II / 2011 finira par être interprété comme novembre.
MSalters
0

Je dirais que cela dépend de ce que vous faites, du degré de contrôle que vous avez sur l'entrée et la stockez-vous quelque part?

Pour le stockage, j'utiliserais ce qui a été suggéré par Mike Dunlavey:

YYYYMMDDHHMMSS où l'heure est en UTC est la façon dont je vais chaque fois que j'ai le choix, pour les raisons que vous donnez. Quand je n'ai pas le choix, je laisse le choix à l'utilisateur.

Il n'a pas laissé cela comme réponse, donc je le ferai.

Une dernière chose: consultez la capture d'écran suivante pour savoir comment entrer la date d'expiration de CC: http://www.ubercart.org/files/credit_card_checkout.jpg

La grande chose à propos de cet exemple est qu'il ne vous fait pas réfléchir. Il utilise à la fois des chiffres et des noms pour le mois. J'envisagerais d'utiliser quelque chose de similaire pour l'entrée. Pour le mois, incluez le numéro et le nom localisé. Pour l'année et le jour, utilisez les zones numériques Haut / Bas ou les zones de liste déroulante. Ensuite, le contrôle du calendrier semble également astucieux.

Comme je l'ai dit, cela dépend. Pour le stockage: si vous utilisez une base de données, vérifiez si elle fournit déjà un bon format de données non ambigu. Si vous utilisez une autre méthode, voyez si "YYYYMMDDHHMMSS où l'heure est en UTC" aide. Pour le présenter à l'utilisateur - prenez en considération les pays / localités susceptibles d'être impliqués, puis choisissez le type de représentation le plus simple, «Ne me faites pas penser». Pensez également à fournir une option.

Enfin, découvrez quelques produits sympas qui font déjà quelque chose de similaire et essayez de savoir comment ils le font.

Emploi
la source
ah merde, en lisant la capture d'écran, je pensais que nous parlions du 11 novembre ... seulement pour réaliser que la journée n'était pas nécessaire lorsque l'on parlait de la date d'expiration de la carte de crédit: /
Matthieu M.
@Matthieu M., oui, c'est un peu trompeur :) Cependant, si vous tenez un CC dans votre main et que vous êtes sur le point d'effectuer la saisie de données, alors peut-être que cela aide plus que ça fait mal. S'il y avait trois boîtes - une pour la journée, alors cela pourrait être moins ambigu.
Job
0

Il n'y a pas de format universel de date et d'heure pour les utilisateurs finaux du site Web. Il n'y a pas non plus de valeur d'heure de date unique car la valeur est différente selon le fuseau horaire du client. Vous devez utiliser la mondialisation - son ciblage des données, de l'heure, de la devise, du calendrier, des formats nubmer basés sur la culture des utilisateurs (peut être reçu à partir des langues acceptées transmises par le navigateur de l'utilisateur ou par un commutateur implémenté directement dans votre application). Certaines API (par exemple .NET) prennent directement en charge ces fonctionnalités.

Pour stocker la date et l'heure dans la base de données, utilisez le format universel - UTC (coordonnée de l'heure universelle).

Ladislav Mrnka
la source
L'UTC n'est pas si universel: si vous voulez prendre en compte les secondes
intercalaires,
-2

Il est regrettable que toute l'intelligence du monde informatique international ne puisse pas casser cette noix.

Ni Microsoft ni les autres fournisseurs n'ont envisagé d'ajouter un masque de date qui ferait apparaître le mois rempli de zéro, un peu comme le jour, mais en trois chiffres. L'adoption de la pratique aiderait à promouvoir une nouvelle série de formats de date modifiés qui sont mathématiquement équivalents tout en restant faciles à identifier et à distinguer dans n'importe laquelle des dispositions de date traditionnelles. C'est:

  • 0MM-DD-YYYY, par exemple 002-03-2016 pour le 03 février 2016

  • DD-0MM-YYYY, par exemple 03-002-2016 pour 03-Feb-2016

  • AAAA-0MM-JJ, par exemple 2016-002-03 pour 2016-02-03

  • YYYY-DD-0MM, par exemple 2016-03-002 (si quelqu'un voulait l'utiliser!)

Semble trop facile à réparer de cette façon ... Je suppose que simple ne se vend pas bien.

FBTHFL
la source
2
Tout ce que je peux dire, c'est: xkcd.com/927 Nous avons déjà une norme ISO pour les dates, et nous n'en avons pas besoin d'une autre.
Simon B