Dates, durées et horloges en informatique

Un temps pour tout, tout pour le temps !

a marqué ce sujet comme résolu.

Tout le monde se secoue ! :D

J’ai commencé (lundi 08 mars 2021 à 22h25) la rédaction d’un tutoriel au doux nom de « Dates, durées et horloges en informatique » et j’ai pour objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limites pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l’adresse suivante :

Merci !


Version 1 du 13 avril : cette version est très loin d’être terminée. En particulier, je ne suis pas convaincu par le plan et l’arrangement entre les parties, par la présentation et la narration du tuto, etc…

Je recherche des retours sur le fond : organisation du contenu, pertinence du contenu lui-même, clarté, hiérarchie des informations… N’hésitez pas à dire franchement ce que vous en pensez, même si vous imaginez qu’il y a de grosse coupes et/ou de grosse sections manquantes.

Il manque encore (manques connus) :

  • Toutes les intros et conclusions : le plan risque de bouger pas mal, je les ferai après.
  • Des illustrations pour casser le côté austère.
  • Des ressources dans l’annexe sur les langages de programmation (n’hésitez pas à proposer les votres).

Ce n’est pas la peine de remonter les problèmes de français en général, je vais encore beaucoup retravaille cet aspect.

Version 2 du 20 juin : cette version devrait être proche de la version finale.

Je prends tous types de retours, y compris les pinaillages sur la forme !

Version 3 du 17 juillet : cette version a été corrigée et est partie en validation ! Mais si vous avez encore des commentaires, il n’est pas trop tard !

Salut, Petit compte rendu de lecture. Intéressant et j’aime bien ton approche. Je pense que l’essentiel est là bien que peut être que je donnerais plus d’exemples.

On se débarrasse vite fait des fautes, je n’ai constaté que deux fautes en première partie :

Du fait de leur précision, les dates sont toujours partielles, dans le sens où à partir d’un niveau de précision, les informations associées ne son plus définies.

Parenthèse en trop :

Résultat, Wikipedia compte pas moins de 20 epoch différentes)

Y’en a une autre mais je ne remets pas la main dessus… Rien de bien méchant, ça m’a sauté aux yeux mais je n’ai pas spécialement cherché la petite bête.

Pour le contenu en lui même, peut être que tu utilises un poil trop les blocs informations, mais en même temps ils sont justifiés. Pas simple, je trouve que cela casse un peu la lecture qu’il y en ait autant de mon point de vue.

Ton approche est bonne dans le sens où tout semble bien défini (même si je connais globalement les pièges que tu as évoqué). La progression me semble correcte, ta distinction date / durée le long du tuto me semble important et pertinent.

Peut être que tu devrais donner plus d’exemples de code plus concrets des problèmes courants. Même si l’essentiel est évoqué sans code, peut être que ça aiderait à identifier un code qui semble valide de loin mais qui dans le détail en fait va merder. En tout cas, je trouverais ça bien mais peut être que selon ton public cible cela pourrait poser soucis.

Par exemple, dans le cas des durées, j’ai souvent vu du code qui par erreur n’utilisait pas l’horloge monotonique. Avec des boucles qui se basent dessus pour définir une durée de pause ou d’attente. Et bien sûr quand un ajustement NTP ou un changement d’heure intervient, boucle infinie car ta nouvelle valeur de comparaison (le nouvel instant présent) peut se situer par exemple 1h avant le point de référence du début de boucle !

Un petit manque aussi, car tu mentionnes à juste titre que les fuseaux horaires bougent tout le temps. Heure d’été / d’hiver décalés, ajoutés ou supprimés selon les pays, pays qui change son fuseau horaire de référence et j’en passe. Tu pourrais mentionner qu’il y a des bases de données contenant ces informations que le système peut manipuler comme tzdata. Et que chose importante, dans le cas d’un système qui n’a pas des mises à jour automatique, il faut maintenir cette base de données à jour pour éviter que le système ne se trompe en cas de changements futurs.

Comme tu peux le voir, globalement pas trop de choses à dire, cela me semble bien dans l’ensemble et donne une bonne vue globale de la problématique.

+1 -0

Salut,

Je trouve que c’est globalement une bonne idée d’aborder ce sujet. C’est rarement fait de façon aussi détaillée, sauf à lire la doc du langage qu’on utilise. C’est donc bien d’avoir un tutoriel agnostique comme celui-ci.

Sur la forme, je trouve aussi pas mal ta tentative d’être le moins géocentrique possible. C’est plutôt bien respecté: tu parles de calendriers liés à des phénomènes astronomiques, de décalage horaire, de manière neutre. Jusqu’à ce passage:

Non, parce que dans ce contexte, « une journée », c’est sans doute 7 heures, et « une semaine », probablement 5 jours de travail (de 7 heures donc). Ou pas : peut-être que votre projet n’est pas géré par une entreprise aux 35 heures, pour quelque raison que ce soit.

Tout à coup on se recentre sur la France. C’est dommage. Le nombre d’heures par semaine n’est pas toujours légalement défini aussi précisément qu’en France, et la semaine de travail peut ne pas avoir 5 jours. Par exemple en Suisse, c’est différent dans chaque entreprise qui a une marge de manoeuvre pour choisir (souvent 42 ou 40, parfois 37.5 ou 45, ou un nombre variable selon la saison dans la construction). Je ne sais pas comment tu pourrais reformuler pour conserver ta présentation générique.

Toujours dans le chapitre des durées, à mon avis tu ne mets pas assez l’accent sur le fait qu’ajouter 86400 secondes n’est pas la même chose qu’ajouter un jour. Plus généralement ça manque d’exemples (mais peut-être que ça viendra ?)

Ca serait aussi bien d’indiquer quelque part explicitement les règles générales d’interaction entre dates et durées quand on fait des calculs:

  • Durée + durée = durée
  • Durée - durée = durée
  • Date + durée = date
  • Date - durée = date
  • Date - date = durée
  • Date + date = impossible
  • durée * nombre entier = durée
  • Durée / nombre entier = impossible à cause des conversions d’unités non équivalentes

Enfin, et parce que j’ai la flemme de faire des recherches la maintenant tout de suite, pourquoi ne pas aborder les questions suivantes:

  • Pourquoi a-t-on choisi le 1er janvier 1970 ?
  • La peur du bug de l’an 2000
  • Le bug du 19 janvier 2038
  • D’autres gros bugs passés (ou peut-être à venir) ? JE fais le parralèle avec un bug d’une fusée ARiane à cause d’erreurs de nombre flottants, y-a-til eu un échec retentissant similaire à cause d’erreurs dans le calcul du temps ?
  • Convertir un timestamp en date UTC ou locale et vice-versa, comment ça marche sous le capot dans les grandes lignes ? Après avoir lu le reste du tuto, on sait maintenant (si on ne savait pas déjà) que ce n’est pas seulement une histoire de multiplications, de divisions et de modulos
  • un petit exemple concret d’algorithme: la date de Pâques

Note à part, un autre tutoriel sur l’histoire du temps de l’antiquité aux ordinateurs serait sans doute intéressant… mais il me semblais en avoir déjà vu un quelque part, peut-être en bêta jamais fini ?

+2 -0

Merci pour vos premiers retours, ça m’est très utile !

Pour le contenu en lui même, peut être que tu utilises un poil trop les blocs informations, mais en même temps ils sont justifiés. Pas simple, je trouve que cela casse un peu la lecture qu’il y en ait autant de mon point de vue.

Renault

Je me suis fait la même réflexion en fait. C’est toujours d’un dosage délicat, surtout que je veux essayer de ne pas trop m’éparpiller… et donc moins de blabla = des blocs plus présent.

Peut être que tu devrais donner plus d’exemples de code plus concrets des problèmes courants. Même si l’essentiel est évoqué sans code, peut être que ça aiderait à identifier un code qui semble valide de loin mais qui dans le détail en fait va merder. En tout cas, je trouverais ça bien mais peut être que selon ton public cible cela pourrait poser soucis.

Renault

C’est une bonne idée, en particulier l’exemple que tu donnes ensuite.

Tu pourrais mentionner qu’il y a des bases de données contenant ces informations que le système peut manipuler comme tzdata. Et que chose importante, dans le cas d’un système qui n’a pas des mises à jour automatique, il faut maintenir cette base de données à jour pour éviter que le système ne se trompe en cas de changements futurs.

Renault

Ha je savais bien que j’avais oublié un truc que je voulais mettre dans la gesti on des fuseaux horaires >_<

Comme tu peux le voir, globalement pas trop de choses à dire, cela me semble bien dans l’ensemble et donne une bonne vue globale de la problématique.

Renault

Tout à coup on se recentre sur la France. C’est dommage. Le nombre d’heures par semaine n’est pas toujours légalement déf ini aussi précisément qu’en France, et la semaine de travail peut ne pas avoir 5 jours. Par exemple en Suisse, c’est différent dans chaque entreprise qui a une marge de manoeuvre pour choisir (souvent 42 ou 40, parfois 37.5 ou 45, ou un nombre variable selon la saison dans la construction). Je ne sais pas comment tu pourrais reformuler pour conserver ta présentation générique.

QuentinC

Oui, la formulation actuelle gagnerait beaucoup à être dé-francisée…

Toujours dans le chapitre des durées, à mon avis tu ne mets pas assez l’accent sur le fait qu’ajouter 86400 secondes n’est pas la même chose qu’ajouter un jour. Plus généralement ça manque d’exemples (mais peut-être que ça viendra ?)

QuentinC

Ça devrait venir, parce que je suis d’accord.

Ca serait aussi bien d’indiquer quelque part explicitement les règles générales d’interaction entre dates et durées quand on fait des calculs:

  • Durée + durée = durée
  • Durée - durée = durée
  • Date + durée = date
  • Date - durée = date
  • Date - date = durée
  • Date + date = impossible
  • durée * nombre entier = durée
  • Durée / nombre entier = impossible à cause des conversions d’unités non équivalentes
QuentinC

Cette remarque est intéressante, parce que mon propos c’est justement qu’on ne peut pas faire d’arithmétique avec des dates (on peut en faire sur des durées, et éventuellement sur les timestamp qui représentent des instants, mais il faut éviter). Par contre on peut faire des opérations qui ressemblent à de l’arithmétique mais qui n’en est pas vraiment (d’où la table logique bizarre que tu donnes).

Mais le fait que tu fasses la remarque montre que le message n’est pas clair.

PS : par contre un tableau des opérations autorisés pourrais être intéressant.

Enfin, et parce que j’ai la flemme de faire des recherches la maintenant tout de suite, pourquoi ne pas aborder les questions suivantes: […]

QuentinC

C’est des points intéressants, mais pour moi qui sont hors du scope du tuto. Ils auraient éventuellement leur place en annexe.

Si ça t’intéresse, je peux t’ajouter en co-auteur pour que tu traites ces sujets.

Sommes-nous bien d’accord que la « planification de tâche » dont il est question fait référence par exemple au système de cron sous Unix (et équivalents dans d’autres systèmes) ?

Dans le contexte, ça me paraît possible, surtout avec les problèmes (hélas) classiques que tu évoques lors du changement d’heure.

Sommes-nous bien d’accord que la « planification de tâche » dont il est question fait référence par exemple au système de cron sous Unix (et équivalents dans d’autres systèmes) ?

Dans le contexte, ça me paraît possible, surtout avec les problèmes (hélas) classiques que tu évoques lors du changement d’heure.

sgble

C’est exactement ce dont je parle.

Qu’est-ce qui te « parait possible » du coup ? (j’ai l’impression qu’il manque un bout de phrase ou du contexte).

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.


Les ajouts concernent : toutes les introductions et conclusions, des précisions diverses, plus d’exemples, des illustrations.

J’ai essayé de faire un tableau des opérations possibles sur les différentes notions vues, mais je n’ai pas réussi à faire quelque chose de synthétique et lisible.

Normalement le texte est complet, il ne lui manque plus qu’une passe de traitement sur la forme, pour dégager toutes les coquilles, les répétitions involontaires, etc.

Je prends les retours de tous types, orthographe/grammaire/style compris !

Qu’est-ce qui bloquait au niveau du tableau des opérations et qui le rendait illisible ?

entwanne

En gros, soit je me retrouve avec un truc gigantesque et inexploitable, soit avec un tableau inexploitable parce qu’il manque les 3/4 des informations, soit avec plein de tableaux inexploitables parce qu’il faut trouver le tableau pour trouver l’information. Rien qui permette de faire ce que je voulais, à savoir avoir une vue d’ensemble sur les opérations possibles, donc.

Quelques autres coquilles passées entre les mailles :

  • « sont la source d'énormément de problèmes » (lien).
  • « le format ISO voulu » (lien) → j’ai l’impression que l’espace derrière ISO est trop fine.
  • « Pour les durées plus longues qu’une année, on retombe souvent sur un système métrique » (lien) → je ne suis pas sûr de l’emploi du mot « métrique » ici. Décimal peut-être ?
  • « bibliothèques de gestion temporelles » (lien) → pas sûr de l’accord de temporelles, suivant s’ils s’accorde avec bibliothèques ou avec gestion.
  • « il est très important de bien se renseigner selon deux axes : » (lien) → tu énumères 3 paragraphes ensuite.
  • « projectDate n’est pas une date » (lien) → il n’y a pas de projectDate dans l’exemple.
  • « on n'a aucune idée de ce qu’on revoie » (lien)
  • « Pour ça il faut, eh bien d’une horloge qui donne la date et l’heure actuelles » (lien)
Ce sujet est verrouillé.