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/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 -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
> >
> >
>
> This is what I explained:
>
> By writing Date("10/01/2016"), you make a logical error that has been
> hidden by the described bug, and a misuse of the Date() function.
>
> Date("10/01/2016") means Date(CDate("10/01/2016")) (as Date() expects a
> date). And so "10/01/2016" has to be interpreted as a GMT date, not a
> local date, as CDate() must not be local-aware.
>
> You have to write Val("10/01/2016") instead, provided that "10/01/2016"
> is actually a local date of course.
>
> Regards,
>
> --
> 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/intel
> _______________________________________________
> Gambas-user mailing list
> Gambas-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>
------------------------------------------------------------------------------
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/intel
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
