I am having a strange issue.

 If Abs(DateDiff(CDate(IDDT), Now(), gb.Minute)) > 90 Then T = False

where IDDT = "07/18/2023 14:30:00"
Now() = "07/18/2023 14:31:12"   —- obviously this changes but that was current value

The result of the line is 482 which clearly is not minutes nor seconds. Is there a glitch or am I doing something wrong?

sadams54 said

I am having a strange issue.

 If Abs(DateDiff(CDate(IDDT), Now(), gb.Minute)) > 90 Then T = False

where IDDT = "07/18/2023 14:30:00"
Now() = "07/18/2023 14:31:12"   —- obviously this changes but that was current value

The result of the line is 482 which clearly is not minutes nor seconds. Is there a glitch or am I doing something wrong?

i think Cdate uses UTC time so it will be different to your own timezones "Date" and "Now" results

If I use CDate here my results are -1 hour out.

We need to find the offset between our own timezones and UTC..

This fixed it for me…

then try this…

If Abs(DateDiff(UTC2Local(CDate(IDDT)), Now(), gb.Minute)) > 90 Then T = False

 That is the problem with using CDate and Date together.

Like i say there are workarounds if you have to use CDate with Date You may want to find another way though.

Maybe it can be changed like this:

vuott said

Maybe it can be changed like this:

Code (gambas)

1. Public Sub UTC2Local(CDateResult As Date) As Date
2.  
3.   Dim d1 As Date = Now
4.  
5.   d1 = DateAdd(CDateResult, gb.Hour, System.TimeZone \ 3600)
6.  
7.   Return d1
8.  
9. End

ooh nice, that looks much better than my solution/workaround

I have never used so did not even know there was a System.Timezone property

so to make that much simpler/better version even shorter…

Or even better as System.Timezone is in seconds…


I just tested it and it works fine here

 thank you I tried the solution but it did not work.

Fear not I found a solution. It seems if I tried to send the results of cdate directly to the function I got something 8 hours in the future. If I assigned the cdate result to a date variable then send that to the function it works perfectly.

Thank you I would never have guessed somebody thought that time should be converted to UTC instead of local time like a normal person.

You guys are great.

Yeah it does warn in the wiki for CDate command..
/lang/cdate - Gambas Documentation

gambas wiki said

Be careful! The current localization is not used by this function.

In other words, if the expression is a string, it is assumed to be a date written in american format at UTC time.

So it is not a conversion to UTC but more of an "expectation" that the given string is UTC.

And ONLY if the argument for CDate is a string. if you send a Date object it does not convert

Thanks to Vuott we have a nice simple way to convert  using System.Timezone
(you'll just have to figure out the way to make either local to UTC and also UTC to local)


If your country's localization uses the same date format as american (m/d/y) then you should not need CDate and can just use normal localized date functions.