Fix off by one date errors on CT reports

The utc conversion was causing it to cut off hours at the end of the
day as enddate would end up being a datetime object with 10pm today.
OK so I think the right convention is to treat dates like dates and
datetimes like datetimes.

With dates there's the question of what "start_date" and "end_date" mean to
you, and your user if it's exposed to them. (Inclusive? Exclusive?)

With datetimes there's no such question. Normally when I've dealt with this
in the past you want start_date and end_date to be (1) _dates_ and (2)
inclusive (because that's what the user expects). You can then separately
have a start_time and end_time which are the first moment of start_date and
then first moment of the day after end_date respectively, and make sure to
do a `time >= start_time`, `time < end_time` query.

Make sense?


On Mon, Jun 23, 2014 at 2:21 PM, Tyler Wymer <notifications@github.com>
wrote:

> In corehq/apps/reports/commtrack/data_sources.py:
>
> > +    def start_date(self):
> > +        if self.config.get('startdate'):
> > +            start = parser.parse(self.config.get('
> startdate')).date()
> > +        else:
> > +            start = (datetime.now() - timedelta(30)).date()
> > +
> > +        return datetime(start.year, start.month, start.day, 0, 0, 0)
> > +
> > +    @property
> > +    def end_date(self):
> > +        if self.config.get('enddate'):
> > +            end = parser.parse(self.config.get('enddate')).date()
> > +        else:
> > +            end = datetime.now().date()
> > +
> > +        return datetime(end.year, end.month, end.day, 23, 59, 59)
>
> Does it? I went back and forth on this one, so that's a serious question.
> Is self.end_date returning tomorrow more logical than doing something
> hacky like this and returning 11:59pm?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/dimagi/commcare-hq/pull/3684/files#r14091018>.
>