Strange behavior in daterange filter

Lukasz_Wyszomirski · May 20, 2015, 10:13am

Hey guys,

I don't know if this is a bug (maybe its made on purpose), but I noticed
in daterange filter some strange behavior in enddate.

For example.
when we choose in daterange filter dates from 01-01-2015 to 10-01-2015
then in startdate we will have 01-01-2015 00:00:00 (this is correct)
but in enddate we will have 10-01-2015 00:00:00 (I thing this is a bug),
we should have 10-01-2015 23:59:59 because when we have time to 00:00:00
then in records we don't include daa from 10-01-2015.

Regards,
Łukasz

Simon_Kelly · May 20, 2015, 12:24pm

Hi

There is a parameter in the DateSpan class that tells it whether to include
the current day or not:

github.com

dimagi/dimagi-utils/blob/master/dimagi/utils/dates.py#L137


      
              today = datetime.datetime.combine(datetime.datetime.today(), datetime.time())
              if type(date) == datetime.date:
                  today = today.date()
              day_after_tomorrow = today + datetime.timedelta(days=2)
          
              return today <= date + datetime.timedelta(days=1 if inclusive else 0) < day_after_tomorrow
          
          
          class DateSpan(object):
              """
              A useful class for representing a date span
              """
              startdate = None
              enddate = None
              format = None
              inclusive = True
              is_default = False
              _max_days = None
          
              def __init__(self, startdate, enddate, format=ISO_DATE_FORMAT, inclusive=True, timezone=pytz.utc,
                           max_days=None):

Though I suspect that there may be some inconsistencies in this code:

github.com

dimagi/dimagi-utils/blob/master/dimagi/utils/dates.py#L336


      
              elif self.max_days is not None:
                  delta = self.enddate - self.startdate
                  if delta.days > self.max_days:
                      return _("You are limited to a span of {max} days, but this date range spans {total} days").format(
                          max=self.max_days, total=delta.days)
              return ""
          
          def __str__(self):
              if not self.is_valid():
                  return "Invalid date span %s - %s" % (self.startdate_param, self.enddate_param)
          
              # if the dates comprise a month exactly, use that
              if (self.startdate.day == 1 and
                      (self.enddate + datetime.timedelta(days=1)).day == 1
                      and (self.enddate - self.startdate) < datetime.timedelta(days=32)):
                  return "%s %s" % (month_name[self.startdate.month], self.startdate.year)
          
              # if the end date is today or tomorrow, use "last N days syntax"
              if today_or_tomorrow(self.enddate, self.inclusive):
                  return "last %s days" % ((self.enddate - self.startdate).days + (1 if self.inclusive else 0))

···

On 20 May 2015 at 12:13, Łukasz Wyszomirski wrote:

Hey guys,

I don't know if this is a bug (maybe its made on purpose), but I noticed
in daterange filter some strange behavior in enddate.

For example.
when we choose in daterange filter dates from 01-01-2015 to 10-01-2015
then in startdate we will have 01-01-2015 00:00:00 (this is correct)
but in enddate we will have 10-01-2015 00:00:00 (I thing this is a bug),
we should have 10-01-2015 23:59:59 because when we have time to 00:00:00
then in records we don't include daa from 10-01-2015.

Regards,
Łukasz

--

--- You received this message because you are subscribed to the Google
Groups "CommCare Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Simon Kelly
Senior Engineer | Dimagi South Africa

Lukasz_Wyszomirski · May 20, 2015, 2:41pm

This make sense, but I'm using this

github.com

dimagi/commcare-hq/blob/master/corehq/apps/reports/filters/dates.py#L9


      
          import datetime
          import json
          
          
from django.utils.translation import gettext as _
          from django.utils.translation import gettext_lazy
          
          
from dimagi.utils.dates import DateSpan, add_months
          
          
from corehq.apps.reports.filters.base import BaseReportFilter
          from corehq.util.dates import iso_string_to_date
          
          

          
class DatespanFilter(BaseReportFilter):
              """
                  A filter that returns a startdate and an enddate.
                  This is the standard datespan filter that gets pulled into request with the decorator
                  @datespan_in_request
              """
              template = "reports/filters/datespan.html"

filter. In property datespan (L22) we using method which you mean but
next we override startdate and enddate by request startdate and enddate.
Where we have time set to 00:00:00.

···

On 20.05.2015 14:24, Simon Kelly wrote: > Hi > > There is a parameter in the DateSpan class that tells it whether to > include the current day or not: > https://github.com/dimagi/dimagi-utils/blob/master/dimagi/utils/dates.py#L137 > > Though I suspect that there may be some inconsistencies in this code: > https://github.com/dimagi/dimagi-utils/blob/master/dimagi/utils/dates.py#L336 > > On 20 May 2015 at 12:13, Łukasz Wyszomirski <lwyszomirski@soldevelo.com > wrote: > > Hey guys, > > I don't know if this is a bug (maybe its made on purpose), but I > noticed in daterange filter some strange behavior in enddate. > > For example. > when we choose in daterange filter dates from 01-01-2015 to 10-01-2015 > then in startdate we will have 01-01-2015 00 > :00:00 (this is correct) > but in enddate we will have 10-01-2015 00:00:00 (I thing this is a > bug), we should have 10-01-2015 23:59:59 because when we have time > to 00:00:00 then in records we don't include daa from 10-01-2015. > > Regards, > Łukasz > > -- > > --- You received this message because you are subscribed to the > Google Groups "CommCare Developers" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to commcare-developers+unsubscribe@googlegroups.com > . > For more options, visit https://groups.google.com/d/optout. > > > > > -- > Simon Kelly > Senior Engineer | Dimagi South Africa > -- > > --- > You received this message because you are subscribed to the Google > Groups "CommCare Developers" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to commcare-developers+unsubscribe@googlegroups.com > . > For more options, visit https://groups.google.com/d/optout.

Simon_Kelly · May 20, 2015, 3:04pm

The 'startdate' and 'enddate' fields should always be what is passed in via
the URL. The original datespan (request.datespan) get's created here:

github.com

dimagi/dimagi-utils/blob/master/dimagi/utils/decorators/datespan.py#L8-8


      
          from datetime import datetime
          from django.http import HttpRequest, HttpResponseBadRequest
          from dimagi.utils.dates import DateSpan
          from dimagi.utils.django.request import request_from_args_or_kwargs
          from dimagi.utils.parsing import ISO_DATE_FORMAT
          
          
          def datespan_in_request(from_param="from", to_param="to",
                                  format_string=ISO_DATE_FORMAT, default_days=30,
                                  inclusive=True, default_function=None):
              """
              Wraps a request with dates based on url params or defaults and
              Checks date validity.
              """
              # you can pass in a function to say what the default should be,
              # if you don't it will pull the value from the last default_days
              # in. If you override default_function, default_days is ignored.
              if default_function is None:

···

On 20 May 2015 at 16:41, Łukasz Wyszomirski wrote:

This make sense, but I'm using this
commcare-hq/corehq/apps/reports/filters/dates.py at master · dimagi/commcare-hq · GitHub
filter. In property datespan (L22) we using method which you mean but next
we override startdate and enddate by request startdate and enddate. Where
we have time set to 00:00:00.

On 20.05.2015 14:24, Simon Kelly wrote:

Hi

There is a parameter in the DateSpan class that tells it whether to
include the current day or not:
dimagi-utils/dimagi/utils/dates.py at master · dimagi/dimagi-utils · GitHub

Though I suspect that there may be some inconsistencies in this code:
dimagi-utils/dimagi/utils/dates.py at master · dimagi/dimagi-utils · GitHub

On 20 May 2015 at 12:13, Łukasz Wyszomirski lwyszomirski@soldevelo.com wrote:

Hey guys,

I don't know if this is a bug (maybe its made on purpose), but I noticed
in daterange filter some strange behavior in enddate.

For example.
when we choose in daterange filter dates from 01-01-2015 to 10-01-2015
then in startdate we will have 01-01-2015 00:00:00 (this is correct)
but in enddate we will have 10-01-2015 00:00:00 (I thing this is a bug),
we should have 10-01-2015 23:59:59 because when we have time to 00:00:00
then in records we don't include daa from 10-01-2015.

Regards,
Łukasz

--

--- You received this message because you are subscribed to the Google
Groups "CommCare Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Simon Kelly
Senior Engineer | Dimagi South Africa

You received this message because you are subscribed to the Google Groups
"CommCare Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups
"CommCare Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Simon Kelly
Senior Engineer | Dimagi South Africa

Lukasz_Wyszomirski · May 20, 2015, 4:57pm

Yes, that is correct, but in url we sent only date without time. And
when we create a datetime object in python then it is added time part
(00:00:00).

Do you think we should change this and in enddate we should set time to
23:59:59?

···

On 20.05.2015 17:04, Simon Kelly wrote: > The 'startdate' and 'enddate' fields should always be what is passed > in via the URL. The original datespan (request.datespan) get's created > here: > https://github.com/dimagi/dimagi-utils/blob/master/dimagi/utils/decorators/datespan.py#L8-8 > > On 20 May 2015 at 16:41, Łukasz Wyszomirski <lwyszomirski@soldevelo.com > wrote: > > This make sense, but I'm using this > https://github.com/dimagi/commcare-hq/blob/master/corehq/apps/reports/filters/dates.py#L9 > filter. In property datespan (L22) we using method which you mean > but next we override startdate and enddate by request startdate > and enddate. Where we have time set to 00:00:00. > > > On 20.05.2015 14:24, Simon Kelly wrote: >> Hi >> >> There is a parameter in the DateSpan class that tells it whether >> to include the current day or not: >> https://github.com/dimagi/dimagi-utils/blob/master/dimagi/utils/dates.py#L137 >> >> Though I suspect that there may be some inconsistencies in this >> code: >> https://github.com/dimagi/dimagi-utils/blob/master/dimagi/utils/dates.py#L336 >> >> On 20 May 2015 at 12:13, Łukasz Wyszomirski <lwyszomirski@soldevelo.com > wrote: >> >> Hey guys, >> >> I don't know if this is a bug (maybe its made on purpose), >> but I noticed in daterange filter some strange behavior in >> enddate. >> >> For example. >> when we choose in daterange filter dates from 01-01-2015 to >> 10-01-2015 >> then in startdate we will have 01-01-2015 00 >> :00:00 (this is correct) >> but in enddate we will have 10-01-2015 00:00:00 (I thing this >> is a bug), we should have 10-01-2015 23:59:59 because when we >> have time to 00:00:00 then in records we don't include daa >> from 10-01-2015. >> >> Regards, >> Łukasz >> >> -- >> >> --- You received this message because you are subscribed to >> the Google Groups "CommCare Developers" group. >> To unsubscribe from this group and stop receiving emails from >> it, send an email to >> commcare-developers+unsubscribe@googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> -- >> Simon Kelly >> Senior Engineer | Dimagi South Africa >> -- >> >> --- >> You received this message because you are subscribed to the >> Google Groups "CommCare Developers" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an email to commcare-developers+unsubscribe@googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. > > -- > > --- > You received this message because you are subscribed to the Google > Groups "CommCare Developers" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to commcare-developers+unsubscribe@googlegroups.com > . > For more options, visit https://groups.google.com/d/optout. > > > > > -- > Simon Kelly > Senior Engineer | Dimagi South Africa > -- > > --- > You received this message because you are subscribed to the Google > Groups "CommCare Developers" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to commcare-developers+unsubscribe@googlegroups.com > . > For more options, visit https://groups.google.com/d/optout.

Strange behavior in daterange filter

-- Simon Kelly Senior Engineer | Dimagi South Africa

--
Simon Kelly
Senior Engineer | Dimagi South Africa