Beware to revision #7983!

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Beware to revision #7983!

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!

--
Benoît Minisini

------------------------------------------------------------------------------
_______________________________________________
Gambas-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Beware to revision #7983!

Karl 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 -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


--
Amicalement
Charlie


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Beware to revision #7983!

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 -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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Beware to revision #7983!

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 <
[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Beware to revision #7983!

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 <[hidden email]>
wrote:

> 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 <
> [hidden email]> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Beware to revision #7983!

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 <[hidden email]>
> wrote:
>
>> 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
>>

I think that you misuse the Date() function too.

Date() is not a string to date conversion function.

You must use:

- CDate() for an UTC date conversion.

- Val() for a local time conversion.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Beware to revision #7983!

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 at 2:53 AM, Benoît Minisini <
[hidden email]> wrote:

> 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 <
> [hidden email]>
> > wrote:
> >
> >> 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
> >>
>
> I think that you misuse the Date() function too.
>
> Date() is not a string to date conversion function.
>
> You must use:
>
> - CDate() for an UTC date conversion.
>
> - Val() for a local time conversion.
>
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Beware to revision #7983!

Jussi Lahtinen
In reply to this post by Benoît Minisini
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

On Tue, Dec 20, 2016 at 2:53 AM, Benoît Minisini <
[hidden email]> wrote:

> 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 <
> [hidden email]>
> > wrote:
> >
> >> 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
> >>
>
> I think that you misuse the Date() function too.
>
> Date() is not a string to date conversion function.
>
> You must use:
>
> - CDate() for an UTC date conversion.
>
> - Val() for a local time conversion.
>
> 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
> [hidden email]
> 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/xeonphi
_______________________________________________
Gambas-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Beware to revision #7983!

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 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Beware to revision #7983!

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, instead of
GMT.


Jussi
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Loading...