Re: [Dolibarr-dev] Question and bug about num_between_day in date.lib.php

[[Kreiz IT] Cédric GROSS]

Humm. It's too late for me playing with date and time zone. What is sure
it's that jdate use a dol_mktime with user timezone so it doesn't return a
UTC/GMT time.
But I think you get this case only because of summer/winter time change
regarding your special interval 28/03/2014 - 31/03/2014.

Bad way ? I think is not a bad way if you use an "if (method_exists(..." or
an "if (function_exist(". There is  one in dol_mktime lol.

Cedric

-----Message d'origine-----
De : address@hidden
[mailto:address@hidden De la part de
Florian Henry
Envoyé : mercredi 5 mars 2014 18:03
À : Posts about Dolibarr ERP & CRM development and coding
Objet : Re: [Dolibarr-dev] Question and bug about num_between_day in
date.lib.php

Ok for the date_create and date_format, I didn't notice it.
I was more thinking to use a DateInterval with date_diff into the method
num_between_day rather than a timestamp substraction / 84600, but it is not
possible for the moment.

For my problem, it's with the standard dolibarr 3.5 (come from github branch
3.5) on the holiday module.
The value send to the function come from the database with the fetch method
of holiday so $this->db->jdate($obj->date_debut);
Just standard of Dolibarr. I use that function in lot's of my modules and it
is the first time I see that.

If I check the record into the database with PhpMyAdmin the date is well
display (31/03/2014) but when I check the timestamp value, I agree with you,
it's not the same things...

But anyway, I solve the issue in a "bad" way for my customer, I use
DateInterval with date_diff in the num_between_day by changing the core file
date.lib.php. It is just another hack of dolibarr for this customer.

Thank's to take time to answer and read my complain.

Regards

Florian HENRY
address@hidden
+33 6 03 76 48 07
http://www.open-concept.pro
Twitter : @_Open_Concept_

Le 05/03/2014 17:19, [Kreiz IT]Cédric GROSS a écrit :
> I haven't a php 5.2 for testing but php documentation defined 
> availability of date_format and date_create for php>=5.2.0.
>
> But anyway, the problem seems not come from num_between_day. From 
> where do you get your timestamp ?
>  From my point of view, you should check that timestamp you send to 
> num_between_day are in UTC without time and that should do the trick.
>
> Cedric
>
> -----Message d'origine-----
> De : address@hidden
> [mailto:address@hidden De la 
> part de Florian Henry Envoyé : mercredi 5 mars 2014 16:40 À : Posts 
> about Dolibarr ERP & CRM development and coding Objet : Re: 
> [Dolibarr-dev] Question and bug about num_between_day in date.lib.php
>
> Yes, the date_create and date_format (available from php 5.3) works, 
> my problem is more on current code and current supported platform.
> As yes I also guess it come from UTC or tzserver time but it do not 
> solve the issue.
>
> Florian HENRY
> address@hidden
> +33 6 03 76 48 07
> http://www.open-concept.pro
> Twitter : @_Open_Concept_
>
> Le 05/03/2014 14:26, [Kreiz IT]Cédric GROSS a écrit :
>> Php directly :
>> $dte=date_create("@$timestampStart");
>> $day1=date_format($dte,'d/m/Y H:i:s'); Echo "$day1\n";
>>
>> You will notice that we go to summer time on 30/03/2014 ;)
>>
>> Hum surely something with time zone. In France we have 1 hour from 
>> UTC in winter and 2 hour from UTC in summer time.
>> May be here is the clue.
>>
>> Cedric
>>
>> -----Message d'origine-----
>> De : address@hidden
>> [mailto:address@hidden De la 
>> part de Florian Henry Envoyé : mercredi 5 mars 2014 14:14 À : Posts 
>> about Dolibarr ERP & CRM development and coding Objet : Re:
>> [Dolibarr-dev] Question and bug about num_between_day in date.lib.php
>>
>> How do you find the value ?
>>
>> 1395961200 = 27/03/2014 23:00:00
>> And
>> 1396216800 = 30/03/2014 22:00:00
>>
>>
>>
>> if I do more debug with a dol_print_date($xxx,'dayhour') I've got this :
>>
>> $timestampStart=1395961200
>> dol_print_date($timestampStart,'dayhour')=28/03/2014 00:00
>>
>> $timestampEnd=1396216800
>> dol_print_date($timestampEnd,'dayhour')=31/03/2014 00:00
>>
>>
>> Regards
>>
>> Florian HENRY
>> address@hidden there a matter around the tmz or gmt 
>> parameters ?
>> +33 6 03 76 48 07
>> http://www.open-concept.pro
>> Twitter : @_Open_Concept_
>>
>> Le 05/03/2014 13:43, [Kreiz IT]Cédric GROSS a écrit :
>>> Hello Henry,
>>>
>>> I just check your timestamp and I get :
>>> 1395961200 = 27/03/2014 23:00:00
>>> And
>>> 1396216800 = 30/03/2014 22:00:00
>>>
>>> So result is quite good (3 days and 23h) may be you should strip 
>>> hour from your timestamp if you wish only "day" difference.
>>>
>>> Cedric
>>>
>>> -----Message d'origine-----
>>> De : address@hidden
>>> [mailto:address@hidden De la 
>>> part de Florian Henry Envoyé : mercredi 5 mars 2014 12:22 À : ML 
>>> Dolibarr Dev Objet : [Dolibarr-dev] Question and bug about 
>>> num_between_day in date.lib.php
>>>
>>> Hi all,
>>>
>>>         I've got a problem into Holiday module, but also can give 
>>> some strange result to other part of code that use function 
>>> num_between_day of date.lib.php
>>>
>>>         My case :
>>>             Find number of day betwenn 21-March-2014 and 
>>> 24-March-2014 Result is 4 => OK (Friday,Saturday,Sunday,Monday)
>>>             Find number of day betwenn 28-March-2014 and 
>>> 31-March-2014 Result is 3 => KO. (Friday,Saturday,Sunday,Monday)
>>>
>>>         If I look into code of this function we have a basic 
>>> timestamp substraction, that should give a good result, but in fact 
>>> not. Is it the only case ? I don't know.
>>>
>>>         I put some trace and there is the result :
>>>
>>>                 21-24 :
>>>                     $timestampStart=1395356400
>>>                     $timestampEnd  =1395615600
>>>                     $bit=0
>>>                     ($timestampEnd - $timestampStart)/(60*60*24) +1 
>>> - $bits
>> = 4
>>>                     floor(4) = 4
>>>
>>>                 28-31 :
>>>                     $timestampStart=1395961200
>>>                     $timestampEnd  =1396216800
>>>                     $bit=0
>>>                     ($timestampEnd - $timestampStart)/(60*60*24) + 1 
>>> - $bits =
>>> 3.9583333333333
>>>                     floor(3.9583333333333) = 3
>>>
>>>
>>>                 As we do a floor on this ($timestampEnd -
>>> $timestampStart)/(60*60*24) the second result is KO
>>>
>>>         If I use the DateTime php object method the result is correct.
>>> But this core php object exists only for php version 5.3 and more. 
>>> So more than the minimum version 5.2.1 describe into the wiki.
>>>
>>>         As patch for now I use round instead of floor but all php 
>>> code line I can found on internet use floor for this type of 
>>> calculation, so what is the good option ?
>>>
>>>         I've create a bug into DoliForge :
>>>
https://doliforge.org/tracker/?func=detail&aid=1287&atid=246&group_id=144
>>>         but still do not have a clue about why the strong 
>>> calculation rule do not work in this specifics case.
>>>
>>> Regards
>>>
>> _______________________________________________
>> Dolibarr-dev mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>>
>>
>> _______________________________________________
>> Dolibarr-dev mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev