[Gambas-user] CDate Documentation

[Benoit Minisini]

Le 13/11/2022 à 17:28, Claus Dietrich a écrit :
>> This could be fixed as suggested several times; assume the user is always
>> correct. IE no conversions.
>> So you would simply get what you give, instead of something unexpected:
>>
>> Print CDate("11/11/2022 13:00:00")     -> 11.11.2022 13:00:00
>> Print CDate("08/11/2022 13:00:00")     -> 08.11.2022 13:00:00
>>
>> But I think it would need its own class or set of methods to maintain the
>> old way people are using.
> 
> I also think, that that no conversion to UTC would have been better. The
> function Date() also doesn't do this and in VBA and Visual Basic 6 CDate
> also doesn't convert to UTC.
> 
> So far and because of the traps I used this function with a time component
> only, which is not converted to UTC. So to me a hard cut would be
> acceptable but this is easily said.
> 
> Brgds
> Claus
> 

You both don't get it.

When transforming a string into a date, there is no such "no conversion" 
thing. You must guess an implicit timezone. Exactly with a string, where 
you have to guess an implicit charset.

So you have CDate(), that uses UTC as timezone, and Val(), that uses the 
timezone of the current localization.

CDate() is the contrary of CStr(). I.e.: CStr(CDate(X)) = X and 
CDate(CStr(aDate)) = aDate. The same way, Val() is the contrary of Str() 
or Print (which uses Str() to print its arguments).

Jussi wants 'CDate()' to act like 'Val()'. But then just use 'Val()', 
not 'CDate()'.

A real enhancement would be to add a syntax to allow to specify the 
timezone explicitely inside the string representation of a date:

CDate("11/11/2020 13:00:00 UTC+2") for example.

Regards,

-- 
Benoît Minisini.