[Gambas-user] Beware to revision #7983!

[Benoît Minisini]

Hi,

In revision #7983, I fixed a bug in date / string conversion, so that 
now, as it is logically expected:

CDate(CStr(CDate(2))) = CDate(2)

BEFORE:

$ gbx3 -e 'CStr(CDate(2))'
01/01/-4801 23:00:00
$ gbx3 -e 'CStr(CDate(CStr(CDate(2))))'
00/00/0000 23:00:00
$ gbx3 -e 'CDate(CStr(CDate(CStr(CDate(2)))))'
Type mismatch: wanted Date, got String instead

AFTER:

$ gbx3 -e 'CStr(CDate(2))'
01/02/-4801
$ gbx3 -e 'CStr(CDate(CStr(CDate(2))))'
01/02/-4801
$ gbx3 -e 'CDate(CStr(CDate(CStr(CDate(2)))))'
01/01/-4801 23:00:00

(Note: The last line is displayed as a local date/time.)

It was not the case before, because the conversion were internally done 
by taking the timezone into account, even if date/time values are 
internally stored in UTC.

Now CDate() on a string always interpret it as an UTC date, and CStr() 
on a date displays its UTC value.

Consequently, check your code!

CStr() and CDate() are not supposed to use a local time representation. 
On the contrary. This is the job of Val(), Str() and Format().

If you wrote code that made that assumption, you did wrong.

BEWARE! BEWARE! BEWARE!

-- 
Benoît Minisini