Je reviens un peu à la charge sur ce sujet, d’autant que l’équipe Substrate n’a pas le même discours :
NOTE: The Timestamp module is the recommended way to query the on-chain time instead of using an approach based on block numbers. The block number based time […] should be avoided.
https://marketplace.substrate.io/pallets/pallet-timestamp/
Dans notre pratique à nous, sur la ĞDev, il y avait parfois des autorités qui ont fait défaut (exemple ici, le coupable étant moi-même) et ont créé des décalages.
Dans le même temps, je trouve important que les promesses fondatrices de notre monnaie la Ğ1 soient respectées :
- la production quotidienne du DU et toujours à la même heure (hors changement d’heure été/hiver);
- sa réévaluation aux équinoxes.
Or justement ces deux promesses sont très sujettes aux erreurs cumulatives de calcul sur les blocs, ces derniers étant particulièrement nombreux (1 bloc / 6s).
Nous avons également d’autres règles basées sur le temps comme celles évoquées dans mon 1er post, mais aussi :
- délai inter-certifications
- délai inter-renouvellement
- délai de confirmation d’identité
- délai de changement de clé publique
- …
Je comprends qu’il soit plus simple de gérer en nombre de blocs. Pour avoir codé Duniter v1, je peux le dire, c’est indéniable. Mais peut-être pouvons-nous faire au cas par cas, selon l’important de la fonctionnalité.
En ce qui me concerne, c’est surtout pour le DU que je préférerais une vraie date GMT pour sa production et sa réévaluation à cause du phénomène d’erreur cumulative.
Pour la plupart des autres utilisations du temps on a moins ce problème : les délais ont une portée limitée puisqu’on n’a pas de continuité comme avec le DU : la certification prend éventuellement plus ou moins de temps, l’adhésion est renouvelée quelques heures plutôt sur les 2 mois normalement nécessaires, mais ce n’est pas significatif. Ces actions étant de toute façon dépendante d’autres aléas humains.
A mon avis, ce sujet devrait être traité avant la migration de la Ğ1.
edit : c’est fait Date de création du DU - #5 by cgeek