There was a bug where since we convert the event's start and end date
into local time for storage in the start_time_notz and end_time_notz
fields, when querying for them we were using the UTC date and time.
For example, assuming an event is scheduled for:
2018-02-07 18:30:00 PST / 2018-02-08 02:30:00 UTC
Then start_time_notz will be the timestamp 2018-02-07 18:30:00.
However, when filtering for "current" events, we looked for events
greater to or equal to the UTC time, so effectively the event would
only be returned until 2018-02-07 18:29:59 UTC (2018-02-07 10:29:59
PST).
To guard against regressions, I've adjusted the test of this data to be
much more precise. (I verified that it failed before the fix.)
This also converts the logic to use the event's end time instead, to
match the logic on the /organizations/<name>/upcoming_events endpoint.
There was a bug where since we convert the event's start and end date into local time for storage in the
start_time_notzandend_time_notzfields, when querying for them we were using the UTC date and time.For example, assuming an event is scheduled for:
2018-02-07 18:30:00 PST / 2018-02-08 02:30:00 UTC
Then
start_time_notzwill be the timestamp 2018-02-07 18:30:00. However, when filtering for "current" events, we looked for events greater to or equal to the UTC time, so effectively the event would only be returned until 2018-02-07 18:29:59 UTC (2018-02-07 10:29:59 PST).To guard against regressions, I've adjusted the test of this data to be much more precise. (I verified that it failed before the fix.)
This also converts the logic to use the event's end time instead, to match the logic on the
/organizations/<name>/upcoming_eventsendpoint.