Age incorrect dans un label

Bonjour à vous...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Private Sub TextBox17_AfterUpdate()   Dim dateEntrée As Date Dim age As Integer, NbAnnées As Integer, NbMois As Integer, nbJours As Integer   If IsDate(TextBox17) Then   dateEntrée = TextBox17.Value NbAnnées = (Year(Now()) - Year(dateEntrée)) NbMois = (Month(Now()) - Month(dateEntrée)) nbJours = (Day(Now()) - Day(dateEntrée))   If NbAnnées > 0 And NbMois > 0 Then age = NbAnnées ElseIf NbAnnées > 0 And NbMois = 0 And nbJours >= 0 Then age = NbAnnées Else age = NbMois End If Lb_age.Caption = age & " ans"   Else Lb_age.Caption = 0   End If End Sub

---

Ce code ci-dessus marche correctement quand je saisis une autre date mais quand je saisis la date de 1998 c'est à dire 19/12/1998, j'obtiens un âge négatif.
Qu'est ce qui fait que la seule date mentionnée (19/12/1998)donne un âge négatif alors que les autres donnent correctement l'âge voulu?
Merci de m'aider

Bonjour

Citation:

---

Envoyé par Mr l'Ashanti

mais quand je saisis la date de 1998 c'est à dire 19/12/1998, j'obtiens un âge négatif.

---

Tu t'es bien compliqué la vie pour faire un raisonnement incorrect car quand tu soustrais 12 à 4 pour les mois tu es en négatif. Avec ceci cela devrait suffire :;

Code:

---

age = (Date - dateEntrée) / 365

---

Merci... Problème résolu. Infiniment merci

Salut.

La division par 365 n'est pas assez précise. il faut diviser par 365.25 pour être un peu plus précis (on peut affiner, bien sûr)

On peut également utiliser DateDiff, par exemple au sein d'une fonction:

Pièce jointe 596927

Dans l'exemple ci-dessus, on voit que la division par 365 amène un résultat erroné (on n'a pas 47 ans le 30/04/2001 lorsqu'on est né le 01/05/1974).

Bonjour Pierre,

Citation:

---

Envoyé par Pierre Fauconnier

La division par 365 n'est pas assez précise. il faut diviser par 365.25 pour être un peu plus précis

---

Pourquoi cherches-tu la précision quand Mr l'Ashanti veux simplement afficher l'age ?

Code:

---

Lb_age.Caption = age & " ans"

---

C'est tout de même rare que lorsque l'on demande l'age d'une personne, l'on attende le nombre de secondes qu'il a vécu, autant adapter selon la demande.:D:mouarf:

Citation:

---

Envoyé par anasecu

[...]
C'est tout de même rare que lorsque l'on demande l'age d'une personne, l'on attende le nombre de secondes qu'il a vécu, autant adapter selon la demande.:D:mouarf:

---

Regarde mon exemple et tu verras que quelqu'un né le 1er mai 1974 a 47 ans avec ta formule (47,0301...), alors qu'il n'aura 47 ans que demain... Et c'est incorrect depuis le 19/04/2021 (car il y a 12 années bissextiles entre 1974 et 2021)... Ca fait pas mal de secondes, ça :ptdr:. C'est tout de même rare que l'on demande l'âge d'une personne à 12 jours près... :D:mouarf:

Quand je parle de précision, je ne parle pas de secondes, évidemment (mais c'est gentil d'avoir essayé de me prendre pour un con), mais du fait que tous les 4 ans, sauf exception séculaire, il y a 366 jours au lieu de 365, ce qui implique que la division par 365 sera d'autant plus imprécise que la personne est âgée.

Si on n'aime pas DateDiff, on peut réaliser une simple soustraction des années et retrancher 1 du résultat si la date d'anniversaire est postérieure à la date de calcul.

Pièce jointe 596963


Il faut noter que DateDif, bien que non documenté, existe dans Excel. A contrario de sa soeur VBA, elle calcule les années entières écoulées, mais étrangement, il faut lui passer le tag "y" (year) et pas "a" (année)... On notera également qu'elle n'est pas reprise dans les Application.WorksheetFunction, mais on peut la traiter en VBA avec Evaluate. Microsoft précise toutefois que cette fonction est présente à des fins de compatibilité avec les anciens classeurs Lotus 1-2-3 et peut produire des résultats erronés dans certaines situations. Je n'ai pour ma part pas rencontré de problème avec le tag "y".

Pièce jointe 596964

De plus, il faut faire attention au transtypage.

La variable age est en Integer dans le code initial, donc l'arrondi naturel joue, ce qui veut dire qu'à 47,5, on passe à 48...

Pièce jointe 596983



J'dis ça, j'dis rien, puisque c'est une question de secondes, pourquoi chercher la précision? :mouarf: :ptdr:

Merci à vous deux... J'apprends mieux sur les dates avec vos explications car ces fonctions sont tellement complexes en réalité que si tu ne maîtrises pas les changements tu te prends un sacré savon. Merci

Citation:

---

Envoyé par Mr l'Ashanti

[...]si tu ne maîtrises pas les changements tu te prends un sacré savon. Merci

---

C'est sûr que si tu dois calculer des primes d'ancienneté et que tu prends 12 jours d'avance dans un calcul de primes, tu vas te faire sonner les cloches :mouarf:

Il faut toujours essayer les solutions qui sont données et ne pas accorder une confiance aveugle aux propositions qui sont formulées, ici ou ailleurs. Certains testent leurs codes de façon professionnelle, d'autres pas et se permettent en plus d'essayer de faire passer les gens pour des cons. Il faut toujours essayer avec plusieurs valeurs, et principalement les valeurs qui sont "critiques". Si on calcule l'âge, il faut tester deux trois dates, mais surtout des dates proches de la date anniversaire (la veille, la date d'anniversaire, le lendemain) pour voir si les valeurs changent selon les attentes.

Et c'est valable pour toutes les fonctions et tous les algorithmes que l'on met en place: Etre attentif aux "effets de bord", tester et retester, surtout les valeurs "limite". C'est la base des bases, que ce soit pour des formules Excel ou pour du code VBA ;) En établissant des tests qui englobent les valeurs limites, tu lèveras les ambiguïtés et les faiblesses de la solution.

Bonne continuation et bon weekend ;)