Strange behavior in daterange filter

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

Hi

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

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

··· 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

This make sense, but I’m using this


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.

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

··· On 20 May 2015 at 16:41, Łukasz Wyszomirski 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

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.