Bitter icon indicating copy to clipboard operation
Bitter copied to clipboard

Question about implementation of bitDateRange

Open strongeye opened this issue 11 years ago • 3 comments

I am looking at the source code of Bitter and had a question about it.

in the function bitDateRange in Bitter.php (line 137+) it looks like you get two different DatePeriods, then do two array_diffs, and it looks like this sometimes will result in bitOfOr being performed twice for the $hoursTo array.

What is the purpose of doing two different calls to DatePeriod::createForHour ?

Here is my analysis of what you are doing (in words):

  • IF the date period is within the same day
    • With $hoursFrom, get all hours within the day
    • With $hoursTo, get just the hours between the start of this day and the $to hour value
  • ELSE // the date period overlaps more than one day
    • With both $hoursFrom and $hoursTo, get actual hours between $from and $to

Is this meaningful? Why do you do anything other than return the actual hour span in all cases? Why do the bitOfOr twice?

Code below

// Hours $hoursFrom = DatePeriod::createForHour($from, $to, DatePeriod::CREATE_FROM); foreach ($hoursFrom as $date) { $this->bitOpOr($destKey, new Hour($key, $date), $destKey); } $hoursTo = DatePeriod::createForHour($from, $to, DatePeriod::CREATE_TO); if (array_diff($hoursTo->toArray(true), $hoursFrom->toArray(true)) !== array_diff($hoursFrom->toArray(true), $hoursTo->toArray(true))) { foreach ($hoursTo as $date) { $this->bitOpOr($destKey, new Hour($key, $date), $destKey); } }

strongeye avatar Sep 17 '13 22:09 strongeye

The aim of doing it "twice" is for doing the following with a dateFrom 2005-06-20 16:53:00 and a dateTo 2007-03-10 08:32:00 as example:

We want the data for theses hours:

  • 2005-06-20 16
  • 2005-06-20 17
  • 2005-06-20 18
  • 2005-06-20 19
  • 2005-06-20 20
  • 2005-06-20 21
  • 2005-06-20 22
  • 2005-06-20 23

Then data for theses days:

  • 2005-06-21
  • 2005-06-22
  • 2005-06-23
  • 2005-06-24
  • 2005-06-25
  • 2005-06-26
  • 2005-06-27
  • 2005-06-28
  • 2005-06-29
  • 2005-06-30

Then data for theses months:

  • 2005-07
  • 2005-08
  • 2005-09
  • 2005-10
  • 2005-11
  • 2005-12

Then data for these year:

  • 2006

Then data for theses months:

  • 2007-01
  • 2007-02

Then data for theses days:

  • 2007-03-01
  • 2007-03-02
  • 2007-03-03
  • 2007-03-04
  • 2007-03-05
  • 2007-03-06
  • 2007-03-07
  • 2007-03-08
  • 2007-03-09

Then data for theses hours:

  • 2007-03-10 00
  • 2007-03-10 01
  • 2007-03-10 02
  • 2007-03-10 03
  • 2007-03-10 04
  • 2007-03-10 05
  • 2007-03-10 06
  • 2007-03-10 07
  • 2007-03-10 08

I hope that help you.

jeremyFreeAgent avatar Sep 17 '13 23:09 jeremyFreeAgent

So I guess it seems that the idea is to capture only for granular time units where the next-level-up unit is not 100% covered, ie. hours that are not a full day, days that are not a full month, months that do not cover a full year, etc.

strongeye avatar Sep 17 '13 23:09 strongeye

Yes, that the point. We could get all the data with the smallest part (hours) but that not really good. Remember that bit works as: does something happened on that day? on that hour? on that year? If something happened this hour, it happened this day so this month so this year.

jeremyFreeAgent avatar Sep 17 '13 23:09 jeremyFreeAgent