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: Florian Henry
Subject: Re: [Dolibarr-dev] Question and bug about num_between_day in date.lib.php
Date: Wed, 05 Mar 2014 16:39:55 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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




reply via email to

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