-
Notifications
You must be signed in to change notification settings - Fork 10
fix: fix timezone issues with current event #714
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Thanks for the PR. Coincidentally, I started working on this and started rethinking the purpose for how we determine the current event. So we currently have this: now = current_timestamp()
lower_bound = datetime.combine(now, datetime.min.time())
upper_bound = datetime.combine(now, datetime.max.time())
# convert back to UTC because datetime.combine() returns
# naive objects
lower_bound = pytz.utc.localize(lower_bound)
upper_bound = pytz.utc.localize(upper_bound)
event = self.filter(
Event.start <= upper_bound, Event.end >= lower_bound
).order_by(Event.start.desc()).first()I forget why we need to fit the current event within the current day. Why not simply use the current timestamp and compare with that instead? I mean it is possible to have several events within the day! No? So I rewrote it as this: now = current_timestamp()
# find events overlapping with the current timestamp and return
# the most recent.
event = self.filter(
Event.start <= now, Event.end >= now
).order_by(Event.start.desc()).first()Thoughts? |
|
it's not usual, but it's happened. for example, i recall an instance when in Nigeria a training event (i believe it was across several states) was split across a single day (a certain state in the morning, with its specific event, another in the afternoon). still, that could be a workflow issue. |
|
What are the drawbacks of simplifying current event retrieval? I've done some testing with the Zambia current set of events and it appears to do what is expected. I'm trying to understand what were the considerations that led us to have a complicated system for determining what event to select as the current one. |
|
i don't think there are any demerits to simply using the timestamp. i guess we were just trying to get a window for active events, instead of an instant. |
|
so this is what it looks like now based on the discussion above: now = current_timestamp(use_app_timezone=True)
event = self.filter(
Event.start <= now, Event.end >= now
).order_by(Event.start.desc(), Event.id).first()
if event:
return event
# if there's no event, pick the closest past event
event = self.filter(Event.end <= now).order_by(
Event.end.desc(), Event.id).first()
if event:
return event
# if there's no event, pick the closest future event
event = self.filter(Event.start >= now).order_by(
Event.start, Event.id).first()
if event:
return event
return None |
|
|
rather than use a day range for the active event query, this commit uses the current instance. it also reverts the implementation of `apollo.utils.current_timestamp`.
takinbo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
see comments on nditech/apollo-issues#41