Using DateDiff and getting errors (1 Viewer)

[Gr3g0ry]

as you can see, the rental date and return date(wich is the expected return date), now when i try to calculate the amount of months that have expried between today, and the expected return date using DateDiff ...

retdate = Me.edate.Value
aretdate = Date
late = DateDiff("m", retdate, aretdate, vbUseSystem)
MsgBox (late)

i get -5

any suggestions on how i can fix this ??

 

[The_Doc_Man]

Try reversing the order of the two date arguments to DateDiff.

But also understand that using larger units (like months) can run into some rounding internally. You might do better to compute days and then divide by 30 (or something similar).

 

[Gr3g0ry]

Try reversing the order of the two date arguments to DateDiff.

But also understand that using larger units (like months) can run into some rounding internally. You might do better to compute days and then divide by 30 (or something similar).

neither of those suggestion worked. instead of -5 im now getting 5 when i reverse the dates, and with the dates reversed when i changed the parameter from "m" to "d" and divided by 30 like you suggested, i still end up with 5

 

[theDBguy]

What is your regional settings?

 

[June7]

"months that have expried between today, and the expected return date"
?DateDiff("m",Date(),#4/25/2024#,vbUseSystem)
This returns 5. What else do you expect?

 

[Gr3g0ry]

"months that have expried between today, and the expected return date"
?DateDiff("m",Date(),#4/25/2024#,vbUseSystem)
This returns 5. What else do you expect?

oh snap ... i didnt even see that ... tyvm. two sets of eyes are better than one. im tired too ... thanks a million.

 

[The_Doc_Man]

OK, when I do the following in the immediate window, this is what I get (today is 11/26/2023 in my timezone):

debug.Print datediff("m", #1/25/2023#, #4/25/2024# )
15

debug.Print datediff("m", Date(), #4/25/2024# )
5

I see no problems here. What date did you expect to see?

By the way, the parameters for DateDiff don't appear to condone "vbUseSystem" as an argument. But as it happens, vbUseSystem translates to 0, which by strange coincidence, is also the default day (Sunday). So you got away with using vbUseSystem in that context. But you could have omitted that last argument and allowed the default to take effect anyway.

 

[June7]

The actual constant is vbUseSystemDayOfWeek which is also 0.
vbSunday is 1.