[Gambas-user] Pre-release of Gambas 3.10.0

[Benoît Minisini]

Le 22/07/2017 à 11:07, Christof Thalhofer a écrit :
> Am 20.07.2017 um 22:49 schrieb Christof Thalhofer:
> 
>> I will try it out at the weekend ... then I have time.
> 
> Next problem I found:
> 
> I have a query against a Postgresql function which returns the
> postgresql type "date".
> 
>     datum
> -----------
>   2012-10-01
>   2012-11-01
> 
> If I query this in Gambas3 through a connection to the database and
> iterate through the result:
> 
> For Each res
>    str &= res!datum & gb.lf
> Next
> print str
> 
> In Gambas 3.9.99 I get:
> 
> 10/01/2012 02:00:00
> 11/01/2012 02:00:00
> 
> In Gambas 3.9 stable I got:
> 
> 10/01/2012
> 11/01/2012
> 
> (All my statistics with gnuplot are fucked up now ...)
> (Yes I know, I should have to format the date)
> 
> 
> Alles Gute
> 
> Christof Thalhofer
> 

This is not a bug, this is a fix. The bug is in the behaviour of Gambas 
3.9 whose CStr() function - which is implicitely used in the line "str 
&= res!datum & gb.lf" - was incorrectly converting using localization, 
whereas CStr() must not be localization-aware (i.e. it must use UTC).

So the interpreter gets the date field contents from the database driver 
as a string.

Then is assumes that string to be a local date, and converts it accordingly.

Then CStr() converts that date back to a string, displaying it in UTC 
timezone (hence your two hours shift).

The actual problem is in the database drivers that always assume that 
dates stored in the database are local dates.

If your database dates are UTC (which should have been the default since 
the beginning, but fixing that would break the backward-compatibility), 
you have to write that:

MyDate = CDate(res!datum + System.TimeZone / 86400)

or

MyDate = Date.ToUTC(res!datum)

if you use the gb.util component from the latest revision.

Regards,

-- 
Benoît Minisini