Discussion :

[Mr l'Ashanti]

Bonjour à vous...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[anasecu]

Bonjour

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

age = (Date - dateEntrée) / 365

[Mr l'Ashanti]

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

[Pierre Fauconnier]

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:



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).

[anasecu]

Bonjour Pierre,

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Pierre Fauconnier]

[...]
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.

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 . C'est tout de même rare que l'on demande l'âge d'une personne à 12 jours près...

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.




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".

[Pierre Fauconnier]

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...





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

[Mr l'Ashanti]

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

[Pierre Fauconnier]

[...]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

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