Vous êtes sûrement sûr que certaines de ces affirmations, sinon toutes, sont toujours et partout vraies:
- Il y a toujours 24 heures dans une journée.
- Une semaine commence et se termine toujours le même mois.
- Une semaine (ou un mois) commence et se termine toujours la même année.
- Le temps n'a ni commencement ni fin.
- Il peut y avoir 28, 29, 30 ou 31 jours dans un mois.
- Il y a une année bissextile tous les 4 ans.
- Chaque mois, le nombre de jours est toujours le même partout.
- Le serveur et le client auront toujours la même heure.
- Vous pouvez facilement calculer le nombre d'heures et de minutes à partir d'un moment donné.
- Chaque minute a 60 secondes.
Bien que la pratique montre qu'il est illusoire de se fier à la véracité de ces déclarations lors du développement de logiciels. Eh bien, d'accord, tous ces points ne sont pas des idées fausses . Certaines affirmations seraient vraies sans les bogues ennuyeux et les cas extrêmes, qui se sont accumulés une myriade au cours de l'histoire du logiciel.
Chaque minute a 60 secondes, et il y a toujours 24 heures dans une journée
Par exemple, dans les anciennes versions de KVM dans CentOS, il y avait un bogue curieux - une minute pouvait durer aussi longtemps que vous le souhaitez. Le fait est que KVM ne savait pas qu'il ne fonctionnait pas sur du matériel physique, et si le système d'exploitation hôte suspendait temporairement la machine virtuelle, alors l'horloge virtualisée continuait de fonctionner à partir du moment où elle était suspendue . Par exemple, si une voiture a été mise en pause à 13h00 et activée à 15h00, l'horloge système continue d'afficher 13h00. En conséquence, après chaque pause, il y avait un décalage avec le temps réel. Il y avait même une tâche cron qui pouvait être configurée pour synchroniser l'horloge virtualisée avec l'horloge matérielle. Mais lors de la création d'une nouvelle machine virtuelle, il était facile de l'oublier et c'était amusant. Le bogue a été corrigé plus tard.
Outre les bugs, il y a aussi une seconde intercalaire (supplémentaire): elle est ajoutée à l'UTC (temps universel coordonné) en fin de journée le 30 juin ou le 31 décembre pour compenser le ralentissement progressif de la rotation de la Terre et l'accumulation de la différence entre le SI et les jours astronomiques - ensoleillé - pendant des jours.
En ce qui concerne la durée de la journée, le principal ennemi du programmeur est le passage à l'heure d'été, qui est quelque part là-bas, quelque part pas, et plus tôt, il pourrait être annulé ou introduit. Il s'agit d'un autre gros problème avec les données historiques - l'heure d'été.
Et si on ajoute à cela le changement de fuseau horaire ...
Environ des semaines, des mois et des années
Mais des histoires sur différentes durées de mois et d'années sont associées à différents calculs de calendrier pour différents peuples du monde. Par exemple, le calendrier hébreu fonctionne avec des mois lunaires: c'est-à-dire que le début et la fin du mois sont liés aux phases de la lune. Pensez-vous pouvoir facilement en tenir compte en ajoutant un ajustement pour Israël avec le chargement des phases lunaires? Ne fonctionnera pas. Dans une année bissextile juive, un mois supplémentaire est ajouté . De plus - faites attention à vos mains - les années simples et bissextiles du calendrier hébreu peuvent avoir trois longueurs différentes . Au total, une année peut avoir six durées différentes.de 354 à 383 jours. Pensez-vous que c'est là que les différences par rapport à notre calendrier se sont terminées? Là où il y en a: dans le calendrier juif, les jours ont des durées différentes et sont comptés du coucher du soleil au coucher du soleil (formellement, lorsque trois étoiles deviennent visibles dans le ciel).
Pensez-vous que ce n'est que pour les juifs que tout n'est pas comme dans le calendrier grégorien (à la question de la grande révolution socialiste d'octobre, célébrée en URSS le 7 novembre)? Dans les pays arabes:
- La semaine ne commence pas le lundi, mais le dimanche.
- Le week-end est considéré comme vendredi et samedi, et dans certains pays - jeudi et vendredi. Au cours des 10 dernières années, certains États ont déplacé le week-end au vendredi et samedi pour faciliter le commerce international. Et pourtant, tous les pays arabes n'ont pas un week-end de deux jours.
- Les fêtes religieuses dépendent des observations du cycle lunaire, de sorte que leur timing ne peut pas être prédit avec précision.
Quant au fait que les semaines et les mois peuvent se terminer l'année prochaine, c'est encore une fois typique des pays avec des calendriers lunaire et solaire-lunaire - dans eux, la nouvelle année ne commence pas le 1er janvier. De façon désinvolte, vous pouvez immédiatement rappeler les Chinois, dont la nouvelle année commence dans la période du 21 janvier au 21 février selon le calendrier grégorien. Et dans le calendrier éthiopien, le nouvel an est généralement le 29 ou 30 août, et même le nombre d'années qu'ils ont est inférieur de 8 à celui du système «depuis la naissance du Christ».
Le serveur et le client auront toujours la même heure
Et voici un fait intéressant, en raison duquel l'heure sur différents ordinateurs peut non seulement ne pas coïncider, mais même la taille de l'écart peut varier. Lorsque Linux démarre, il prend le temps matériel actuel, puis le compte à rebours, en ajoutant des données à partir de l'horloge du processeur interne (TSC). Ces horloges peuvent être assez inexactes. Par exemple, en raison de la mise à l'échelle de l'horloge, qui modifie dynamiquement la fréquence TSC. Et si vous modifiez la fréquence d'horloge sur l'hôte, tous les comptes invités ne le remarqueront même pas. Si vous mettez à l'échelle la fréquence TSC de 50%, le temps commencera à fonctionner deux fois plus lentement. De plus, sur certains serveurs, le BIOS peut mettre à l'échelle la fréquence du processeur sans avertir le système d'exploitation, ce qui ajoute également une erreur. Sur les processeurs plus récents, les fréquences TSC sont désormais fixes. À propos, Windows n'utilise pas TSC, ce système d'exploitation a donc d'autres problèmes de synchronisation:)
Vous pouvez facilement calculer le nombre d'heures et de minutes à partir d'un moment donné
À moins qu'il n'y ait quelque chose comme Python dans le langage de programmation
tzinfo()
, vous ne pouvez pas obtenir une date et une heure spécifiques en ajoutant simplement des heures et des minutes à une date dans le passé. Il faut prendre en compte les fuseaux horaires (et leur éventuel changement, comme cela s'est produit plus d'une fois dans l'histoire), puis prendre en compte tous les changements dans le passage à l'heure d'été ... Sous Windows, c'est généralement impossible, car Microsoft ne fournit que le début et la fin de l'année en cours. Étonnamment, après tant de correctifs de gestion DST, la société n'a toujours pas implémenté d'équivalent Windows
tzinfo()
. Probablement pas.
Le temps n'a ni commencement ni fin
"Votre programme n'aura jamais besoin de gérer des dates antérieures à 1970." Sur les systèmes Unix (y compris Linux et iOS), le temps est compté en secondes depuis 00:00:00 le 1er janvier 1970 UTC (temps universel coordonné). Tout ce qui précède dans Unix sera déjà un temps négatif. De plus, l'heure est représentée dans une expression entière de 32 bits et la date la plus ancienne possible dans les systèmes Unix est le 13 décembre 1901. Et l'heure Unix "top" est limitée au 19 janvier 2038, lorsque le nombre de secondes depuis le début du compte à rebours atteint 2 31 , et ce nombre peut être considéré comme négatif par le système.
Tout cela n'est qu'une petite partie du grand nombre de nuances et de bugs auxquels les développeurs de tout produit prenant du temps doivent faire face. Vous avez sûrement aussi une histoire à raconter de votre expérience, écrivez dans les commentaires.