[Gambas-user] CDate Documentation

Claus Dietrich claus.dietrich at freenet.de
Mon Nov 14 12:43:42 CET 2022

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

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

More information about the User mailing list