Le 15/01/2017 à 16:58, Jussi Lahtinen a écrit : > Benoit is it possible add this timezone conversion suggestion to CDate()? > > Date = CDate ( Expression AS Variant [, InputTimeZone AS Integer, > OutputTimeZone AS Integer ] ) AS Date > > This way you could tell CDate what is the timezone you are using and in > what timezone you need the answer. I think it would decrease the confusion > and add new functionality. > > What do you think? > > > Jussi >
Actually there is no confusion anymore, as this is the old behaviour that was illogical (i.e. CDate(CStr(x)) was not equal to x is some cases). Internal date are always stored in GMT. The confusion comes when you transform them into a string or from a string. The rule now is: - CStr & CDate always use GMT. - Str & Val always use the current locale timezone. But I agree with you that conversion functions with explicit time zone would be useful. Alas CDate() and CStr() cannot be modified (they must take one argument only), so another one should be created. I will think about that. -- Benoît Minisini ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
