Il y a deux façons de gérer le temps et deux façons pour le prendre en compte.
C’est la suite des articles Horodatage, ISO 8601, suite et Marque de temps.
La référence de temps, ou pas
On peut gérer le temps comme étant un prérequis commun à tous les acteurs. Dans ce cas, toutes les machines doivent synchroniser leurs horloges internes sur une source commune. Tout le monde travaille avec la même heure, le même espace temps et la même référence. Ici on ne tient pas compte du fuseau horaire qui est un bricolage de décalage non pas temporel mais sur l’affichage uniquement. Aujourd’hui, l’orientation de tous les systèmes d’informations, c’est la synchronisation globale, c’est à dire la même partout sur la planète.
On pourrait aussi simplement considérer que chaque machine, chaque utilisateur, a un espace temps qui lui est propre. Pas de synchronisations à faire mais se pose alors l’interprétation d’une date donnée par une autre machine. Il faut prévoir un mécanisme de correction du temps des autres machines, par rapport à une référence. On retrouve cette référence commune mais elle peut dans certains cas être soi-même, c’est à dire je suis à la bonne heure et je compense l’heure des autres. En cas d’absence de référence externe, il faut retenir le décalage de chacune des machines avec lesquelles on communique.
Avoir une référence commune implique une communication régulière avec cette référence. Il faut donc une connexion réseau, même partielle. Plus la précision attendue dans la synchronisation est forte, plus les moyens tant en réseau qu’en relais doivent être importants, rapides et fiables. Sur des réseaux isolés ou fortement fragmentés, la synchronisation du temps devient illusoire. Et cela peut arriver partout sur la planète : catastrophe naturelle, guerre, dictature, repli sur elles-même des nations, etc…
Le problème sur la référence de temps n’est pas que théorique. Ce ne serait pas « juste un problème d’affichage ». Beaucoup de protocoles de sécurisation s’appuient aujourd’hui sur le temps et exigent un horodatage assez précis. Lorsque l’on se connecte au site web de sa banque, lorsque l’on renvoie un message signé, lorsque l’on se connecte à un réseau d’entreprise, les jetons de session et autres certificats électroniques ont une durée de vie limitée ou une date d’expiration. Tous ces services impliquent d’avoir un réseau pour fonctionner et peuvent délivrer une référence de temps en même temps que ces services. Par contre, des documents comme les passeports sont aussi émis avec une date d’expiration et il serait difficile de vérifier leur validité sans une référence de temps commune.
Le système de gestion du temps dans nebule est encore aujourd’hui basé sur l’horloge interne de la machine qui exploite les liens. Il utilisera aussi l’entité kronos comme référence. Mais il est prévu de calculer et mémoriser les décalages de temps entre machines. Cette capacité à mémoriser les variations de temps rend l’ensemble plus résilient en cas de catastrophe ou tout simplement de fragmentation volontaire des réseaux. A faire…
Sur un réseau maillé comme sur Internet, la structure globale ressemble à un fractal dans lequel on peut zoomer et retrouver les mêmes formes de connexions entre nÅ“uds de réseau. Un réseau Internet fragmenté serait sûrement toujours maillé et toujours interconnecté, mais la structure globale ressemblerait plutôt à une nébuleuse, c’est à dire sans structure marquée. Dans ce deuxième cas, les synchronisations de temps seraient souvent conflictuelles.
Le postulat que l’on peut simplement synchroniser tout le monde sur une seule et unique référence de temps est une facilité de notre époque. Mais c’est une facilité qui n’est ni évidente ni définitivement acquise.
Prise en compte des événements futurs, ou pas
Avec synchronisation du temps entre les machines ou pas, il peut arriver d’une marque de temps soit dans le futur ou interprétée comme telle. Que fait-on dans ce cas ? Est-ce une erreur de l’émetteur ? Est-ce une erreur de synchronisation ? Est-ce une erreur de zone de temps ? Est-ce un acte malveillant ?
Et c’est pareil pour une date du passé qui ne correspond manifestement pas à l’ère informatique. Est-ce une erreur de référence de temps ?
On peut tenir compte d’une marque de temps problématique et l’interpréter telle quelle vis-à -vis des autres date. Dans le cas d’une suppression de lien marqué dans le futur, cette suppression est valable. Mais, parce qu’elle est dans un futur un peu lointain, il va devenir impossible de réhabiliter ce lien avant cette date puisque sa suppression sera toujours valide temporellement. Il faudrait un nouveau lien plus loin dans le futur qui, lui, empêcherait la suppression avant cette nouvelle date dans le futur… On ne s’en sort pas.
On peut ne pas tenir compte d’une marque de temps invalide et l’écarter du traitement comme étant incohérente. Dans ce cas un lien de suppression dans le futur ne serait plus utilisé avant que notre espace temps ne soit arrivé effectivement à cette date.
Mais dans ce cas la synchronisation de temps ou l’utilisation d’une référence de temps a beaucoup plus d’importance puisque des dates du calendrier arabe, hébraïque, indien, chinois ou copte n’ont pas la même signification. Des événements interprétés comme étant dans le futur seront automatiquement ignorés alors qu’ils sont peut-être valides.
La non prise en compte de liens avec une date dans le futur semble la meilleur solution, mais elle n’est pas encore implémentée dans nebule. A faire…
L’implémentation doit aussi permettre de gérer sereinement les décalages, prévisibles, du temps entre différentes machines même si elles ont la même référence de temps. En dessous de la seconde, une synchronisation globale est illusoire. Avec une connexion à Internet intermittente, une précision de l’ordre de la minute est plausible. Il faut donc prévoir un paramètre afin de définir le décalage maximal de temps que l’on accepte pour des liens dans le futur.
L’utilisation de la norme ISO8601 est indispensable mais pas suffisante. Tous les calendriers n’utilisent pas cette forme et bien sûr n’ont pas la même référence de temps. De plus, si il permet une grande précision, il ne permet pas de manipuler le temps sur ce que l’on appelle le temps long. Il serait intéressant de pouvoir manipuler d’autres calendriers, peut-être avec un préfixe spécifique.
Lien juste à temps
Les liens de nebule n’ont pas vocation à permettre un traitement complexe des données, juste à permettre leur transmission et faciliter le traitement.
Manipuler des données avec des échéances n’est possible qu’en associant un objet contenant une date avec un objet méta spécifique. Le traitement à échéance est réalisé par le programme qui interprète cette forme de lien. Il est facile de réaliser au niveau des liens d’une prise en compte « à retardement » d’un lien. Le modèle pourrait être l’encapsulation d’un lien dans un autre lien d’un type particulier, sur le modèle du lien offusqué. Au lien d’une clé de chiffrement, ce pourrait être une date de prise en compte.
Ce nouveau type de lien est de fait en concurrence avec un lien avec une date dans le futur. Mais cela présenterait quand même quelques avantages. Le premier, c’est que la date pourrait être aussi une période de prise en compte. Mais surtout, là où un lien dans le futur pourrait être supprimé parce que considéré invalide, un lien dédié à cet usage serait beaucoup plus légitime.
Cette idée est encore à réfléchir…
