Annexes

On l’a vu, les dates, c’est compliqué. Ce qui implique que les interactions avec les utilisateurs humains vont être complexes, ce qui mérite une annexe pour parler un peu de tout ça.

Afficher des dates à l’utilisateur

La taille compte, la précision aussi

Une date, ça peut être long, surtout quand on choisit un format d’affichage un peu verbeux :

Dimanche 26 septembre 2021 à 23 heures et 18 minutes

Le choix de votre format d’affichage doit donc dépendre de la place disponible (et qu’il est raisonnable d’accorder) dans votre interface.

N’oubliez pas de prendre en compte les précisions des dates montrées : un simple « 2021 » sera de peu d’aide pour un rappel de rendez-vous, tandis qu’un « dimanche 26 septembre 2021, 23:18:07.014 » sera un peu trop spécifique pour un rappel d’anniversaire.

Enfin, selon le contexte, ne montrer qu’une date partielle peut être une solution à condition que l’on puisse toujours retrouver facilement la date complète en cas de doute. Une page d’accueil de blog peut tout à fait indiquer que le dernier article a été publié « le 3 juin », mais c’est important d’avoir l’information de l’année quelque part dans le texte, pour que l’utilisateur puisse vérifier que l’article n’est pas une vieillerie périmée.

La langue et le pays

Si votre application a une portée internationale, vous devrez gérer l’internationalisation des affichages de dates.

Le problème, c’est que les formats de date dépendent de la langue et du pays de l’utilisateur, et donc sont particulièrement casse-pieds à gérer.

Et ne pas les gérer – surtout si votre logiciel est disponible en plusieurs langues – c’est créer une confusion pour vos usagers. Aucun format de date n’est réellement universel et ne sera compris sans ambigüité partout. En particulier, le fameux format « anglais » mois/jour/année que l’on retrouve souvent dans les logiciels en anglais est en fait… un format purement nord-américain, et utilisé exclusivement aux USA et au Canada anglophone, et dans aucun autre pays anglophone.

Donc, si vous gérez un logiciel international, laissez vos utilisateurs choisir leurs formats d’affichages de date soit directement, soit en employant les standards de la langue et du pays qu’ils renseigneront.

C’est normalement assez simple à faire, parce que le système d’exploitation (sur ordinateur ou smartphone) fournit les formats à utiliser… sauf si vous développez pour du web – ce qui est quand même très courant.

Les dates relatives

Présenter des dates « relatives à maintenant » (« Il y a X minutes », « Il y a X jours », etc.) peut être considéré comme pratique… ou très pénible selon les utilisateurs. C’est à vous de voir à quel point c’est intéressant dans votre application.

Faire saisir des dates à l’utilisateur

Si vos utilisateurs doivent saisir des dates, vous avez le choix entre utiliser un calendrier pour ce faire, ou les laisser taper les dates au clavier. L’idéal étant sans doute de proposer les deux fonctionnalités, avec l’accent plutôt mis sur l’une ou l’autre selon la destination de votre application. Une interface manipulée par le très grand public aura besoin d’un calendrier le plus clair possible ; une interface professionnelle dans laquelle les usagers vont renseigner des dates au kilomètre va profiter d’une bonne zone de saisie texte.

Afficher un calendrier

Employez un vrai calendrier à l’ergonomie soignée, et pas une simple série de dropdown qui obligera l’utilisateur à des dizaines de clics et à fouiller dans une très longue liste pour trouver l’année qui l’intéresse.

Si votre système limite les dates valides à la saisie, indiquez clairement dans le calendrier quelles sont les dates valides et quelles sont les dates invalides.

Utiliser une zone de saisie de texte

Indiquez clairement le format attendu, quel qu’il soit ! Si vous pouvez simplifier la vie des utilisateurs en lui évitant de saisir les séparateurs (exemple : l’usager entre 01022003 et l’interface affiche un joli 01 / 02 / 2003, c’est encore mieux. Ça n’a l’air de rien, mais dans un progiciel ou toute autre application où on renseigne beaucoup de dates, c’est très appréciable.

C

Horloge monotone

• clock_gettime avec le paramètre CLOCK_MONOTONIC ou CLOCK_MONOTONIC_COARSE au moins sous Linux. Cette version n’est pas tout à fait monotone car affectée par les ajustements faits par adjtime ou NTP.

C++

Horloge monotone

std::chrono::steady_clock depuis C++11. L’origine du chronomètre dépend du contexte.

Go

Horloge monotone

time.Now() dans le package time. L’horloge peut ne pas être monotone en cas de mise en veille ou d’hibernation de la machine. L’origine du chronomètre est celle de l’heure POSIX (1er janvier 1970 à minuit UTC).

Java

Horloge monotone

System.nanoTime() depuis Java 1.5. L’origine du chronomètre est au démarrage de la JVM, et l’horloge peut ne pas être monotone en cas de mise en veille ou d’hibernation de la machine.

JavaScript / TypeScript

Horloge monotone

performance.now() qui renvoie un DOMHighResTimeStamp. L’origine du chronomètre dépend du contexte.

PHP

Horloge monotone

hrtime() depuis PHP 7.3. L’origine du chronomètre est inconnue.

Python

Horloge monotone

time.monotonic() (depuis Python 3.3) et time.monotonic_ns() (depuis Python 3.7). L’origine des chronomètres est indéfinie.

Rust

Horloge monotone

std::time::Instant dont l’origine est inconnue.