Re: [Gambas-user] Beware to revision #7983!

2017-01-15 Thread Jussi Lahtinen
> Internal date are always stored in GMT. The confusion comes when you > transform them into a string or from a string. > This is exactly what I meant. I think it should be more clear in the documentation that output of CDate() is in GMT (same as UTC?) and input is assumed to be local date, instea

Re: [Gambas-user] Beware to revision #7983!

2017-01-15 Thread Benoît Minisini
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 us

Re: [Gambas-user] Beware to revision #7983!

2017-01-15 Thread Jussi Lahtinen
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 w

Re: [Gambas-user] Beware to revision #7983!

2016-12-19 Thread Jussi Lahtinen
This is how I do it currently in GAlarm: I save the date variable this way: Settings[sPath &/ "Date&Time"] = CFloat(hAlarm.hTotal) And load it this way: hAlarm.hTotal = Settings[sPath &/ "Date&Time", Null] So, no more string conversions, but it's still not right... Jussi On Tue, Dec 20, 2016

Re: [Gambas-user] Beware to revision #7983!

2016-12-19 Thread Benoît Minisini
Le 20/12/2016 à 01:23, Jussi Lahtinen a écrit : > Or additional requirement for the string, examples "10/01/2016 GMT" or > "10/01/2016 Local". > > > Jussi > > On Tue, Dec 20, 2016 at 2:16 AM, Jussi Lahtinen > wrote: > >> That is bit confusing. Would it be better if Date() function would accept >>

Re: [Gambas-user] Beware to revision #7983!

2016-12-19 Thread Jussi Lahtinen
Or additional requirement for the string, examples "10/01/2016 GMT" or "10/01/2016 Local". Jussi On Tue, Dec 20, 2016 at 2:16 AM, Jussi Lahtinen wrote: > That is bit confusing. Would it be better if Date() function would accept > one more argument "TimeZone". > Example: > > Date("10/01/2016",

Re: [Gambas-user] Beware to revision #7983!

2016-12-19 Thread Jussi Lahtinen
That is bit confusing. Would it be better if Date() function would accept one more argument "TimeZone". Example: Date("10/01/2016", gb.GMT) or Date("10/01/2016", gb.Local) What you think? Jussi On Tue, Dec 20, 2016 at 1:50 AM, Benoît Minisini < gam...@users.sourceforge.net> wrote: > Le 20/

Re: [Gambas-user] Beware to revision #7983!

2016-12-19 Thread Benoît Minisini
Le 20/12/2016 à 00:13, Charlie Reinl a écrit : > 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

Re: [Gambas-user] Beware to revision #7983!

2016-12-19 Thread 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 -

[Gambas-user] Beware to revision #7983!

2016-11-18 Thread 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/ 23:00:00 $ gbx3 -e 'CDate(CStr(CDate(CStr(CDat