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

Reply via email to