[Gambas-user] CDate Documentation

[Benoit Minisini]

Le 14/11/2022 à 12:43, Claus Dietrich a écrit :
> I agree with Jussi. Here is my summary of concrete arguments to change 
> the CDate() function:
> 
> 1. Visual Basic is not inconsistent - Gambas is inconsistent because
> a. Other than CDate() the Date() function of Gambas doesn't convert to UTC
> b. The CDate() function potentially delivers a wrong UTC time
> because it always applies the current UTC offset instead of the real
> offset
> 
> 2. To get a timestamp, the user has to decide, whether he wants
> a local or UTC timestamp. Other than in Visual Basic it can easily
> be recalculated with System.Timezone in Gambas.
> 
> 3. Other than CDate() the Val() function the string representation
> of a date must comply with the locale of the platform. This is
> a different capability and may impose inconsistencies for
> applications if used in different regions.
> 
> 4. For timestamps Gambas also provides Unix-timestamps.
> 
> 5. Timestamps transported over the Internet sometimes contain a
> time zone information:
> Gas prices here in Germany are i.e. delivered with following timestamp:
> 2022-07-20 23:10:09+02
> 
> 6. Although we don't want a Visual Basic clone, we should at least
> take note that CDate() in VB doesn't convert to UTC and should
> reflect whether a deviation is necessary.
> 
> With best regards
> Claus
> 

You don't understand:

1) That the Gambas 'Date' datatype is a timestamp, not a local 
representation of a date.

2) That a timestamp is the representation of a *absolute physical 
instant*. It is not relative like a string representation of a date.

If you can't get with this logic, because you still mix relative 
representation of time and absolute representation (as shown by your 
point #5), just create your own "date" datatype. Or, in other words, 
store your dates as strings.

Gambas will keep its logic, because it's logic, and CDate() won't 
change, because it will break programs.

Regards,

-- 
Benoît Minisini.