dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: [Kreiz IT] Cédric GROSS
Subject: Re: [Dolibarr-dev] Question and bug about num_between_day in date.lib.php
Date: Wed, 5 Mar 2014 17:19:57 +0100

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]