[Gambas-user] Beware to revision #7983!

[Charlie Reinl]

Am Freitag, den 18.11.2016, 16:05 +0100 schrieb 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!
> 

Salut Benoît and Everyone,

I used for many moons this: format(Date("10/01/2016"),"mmmm yyyy") 
and I didn't felt me concerned by that mail......but:

format(Date("10/01/2016"),"mmmm yyyy") 
	gives September 2016 now, gave Oktober 2016 before, 
because Date("10/01/2016") returns 30.09.2016 00:00:00 now (at leased
here in Germany). But that is one day lost.
I checked that now on Gambas=3.9.90 r8012 but was also on Revision: 8004


-- 
Amicalement
Charlie