Description

Retrouvez ci-dessous la traduction EN → FR de l’article “Falsehoods programmers believe about time”, écrit par l’auteur Noah Sussman, sous Licence CC-By.

Fausses croyances des développeurs à-propos du temps

(…)

Toutes ces hypothèses sont fausses :

1. Il y a toujours 24 heures dans une journée.
2. Les mois ont soit 30 ou 31 jours.
3. Les années ont 365 jours.
4. Février a toujours 28 jours.
5. Une période de 24 heures commencera toujours ou terminera durant le même jour, (ou la semaine, ou le mois).
6. Une semaine commence toujours et termine dans le même mois.
7. Une semaine (ou un mois) commence toujours et termine dans la même année.
8. La machine sur laquelle le programme fonctionne sera toujours dans le fuseau horaire GMT.
9. OK, ce n’est pas vrai. Mais au moins le fuseau horaire dans lequel le programme fonctionne ne changera jamais.
10. Bien, assurément il n’y aura jamais de changement de fuseau horaire dans lequel un programme s’exécute en production.
11. L’horloge système sera toujours paramétrée à une heure locale correcte.
12. L’horloge système sera toujours paramétrée à une heure qui n’est pas très différente de l’heure locale correcte.
13. Si l’horloge système est incorrecte, il y aura toujours le même nombre constant de secondes.
14. L’horloge du serveur et celle du client seront toujours paramétrées sur la même heure.
15. L’horloge du serveur et celle du client seront toujours paramétrées à peu près à la même heure.
16. OK, mais l’heure du serveur et celle du client ne seront jamais différentes au-delà de la maîtrise des décennies.
17. Si l’horloge du serveur et celle du client ne sont pas synchronisées, elles seront toujours au moins désynchronisées d’un nombre constant de secondes.
18. L’horloge du serveur et celle du client utiliseront le même fuseau horaire.
19. L’horloge système ne sera jamais paramétrée sur une heure d’un passé distant ou d’un lointain future.
20. Le temps n’a pas de commencement et pas de fin.
21. Une minute d’une horloge système a exactement la même durée qu’une minute sur une autre horloge.
22. OK, mais la durée d’une minute d’une horloge système sera la plus proche de la durée d’une minute sur la plupart des autres horloges.
23. D’accord, mais la durée d’une minute d’une horloge système ne sera jamais plus grande que celle d’une heure.
24. Tu n’es pas sérieux.
25. La plus petite unité du temps est la seconde.
26. OK, une mili-seconde
27. Il ne sera jamais nécessaire de régler l’heure du système sur une autre valeur que celle de l’heure locale correcte.
28. OK, les tests peuvent nécessiter le paramétrage de l’heure du système sur une autre valeur que celle de l’heure locale mais il ne sera jamais nécessaire de faire cela en production.
29. L’horodatage sera toujours spécifié dans un format communément compris, tel que 1339972628 ou 133997262837.
30. L’horodatage sera toujours spécifié dans un même format.
31. L’horodatage aura toujours le même niveau de précision.
32. Un horodatage d’une précision suffisante peut être considéré unique en toute sécurité.
33. Un horodatage représente l’heure à laquelle un événement s’est produit.
34. Les dates humainement compréhensibles peuvent être spécifiées dans un format universellement compris tel que 05/07/11.

La réflexion à-propos du fait que la minute puisse être plus longue qu’une heure est une blague, n’est-ce pas ?

Non.

C’est un fascinant bogue dans de vieilles version de KVM sur CentOS. Spécifiquement, une machine virtuelle KVM ne savait pas qu’elle ne fonctionnait pas sur du matériel physique. Cela signifiait que le système hôte mettait la VM dans un état de veille, l’horloge système virtualisée conservait le temps qu’elle avait au moment de sa suspension.

P. ex. si la VM était suspendue à 13:00 et qu’elle était remise à un état d’activité deux heures plus tard (à 15:00), l’horloge système sur la VM reflétait toujours l’heure locale à 13:00. Le résultat était que chaque fois qu’une machine virtuelle KVM devenait inactive, l’OS hôte la mettait dans un état suspendu et l’horloge système de la machine virtuelle commençait à s’éloigner de la réalité, parfois d’une large marge en fonction de la durée pendant laquelle la machine virtuelle était restée inactive.

Il y avait une tâche cron qui pouvait être installée pour garder l’horloge système virtualisée en ligne avec l’horloge matérielle de l’OS hôte. Mais il était facile d’oublier de le faire sur de nouvelles VMs et l’échec à le faire a conduit à beaucoup d’hilarité. Le bogue a été corrigé dans les versions plus récentes.

Le reste n’est volontairement pas traduit du fait de remerciements de l’auteur envers plusieurs personnes…

Historique

J’ai écrit historiquement cette traduction sur le wiki de la communauté “OpenBSD Pour Tous”.