Skip to content
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

fix: Date range generation for persons_urls #11468

Closed
wants to merge 32 commits into from

Conversation

benjackwhite
Copy link
Contributor

@benjackwhite benjackwhite commented Aug 24, 2022

Problem

Closes #11466

Might close #11352
Might close #9565

Related to #11492

Persons URLs with timezone offsets were not working. This attempts to fix this by ensuring the date_from and date_to params are set accurately and are respected by the persons endpoint.

NOTE This is a bit tricky and should be looked at carefully. A few things were happening that causes some unexpected results

  1. We modify the date_to param by default to be the "end of the day" if the interval is anything other than an hour.
  2. This means a given date from the frontend like date_from=2022-08-20T22:00:00Z&date_to=2022-08-21T22:00:00Z (2022-08-21 UTC+2) will have the date_to modified to 2022-08-21T23:59:59Z (naively the end of the day) which is now a 26 hour window rather than 24
  3. As we were previously relying on this override, we set date_to the same as date_from in the persons_urls which would work for UTC (it would get bumped to 23:59:59 that day) but breaks for any non-utc timezones (which explains many reports of wrong numbers in the persons modal). This is most noticeable by UTC+N timezones rather than UTC-N timezones.

I think we should not override the date_to param but rather respect it always. This way date_from+date_to pair takes precedence with interval only used for bucketing

Changes

  • This is a bit tricky and should be looked at carefully. A few things were happening that

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

How did you test this code?

  1. Set my local project to UTC+2
  2. Opened persons for a given day in a trend and saw no results
  3. Applied this fix
  4. Saw results

Some tests but more should really be added to cover these edge-casey timezone issues

TODO:

@benjackwhite benjackwhite requested a review from timgl August 25, 2022 07:43
@benjackwhite
Copy link
Contributor Author

@timgl tagging you as the changes here to this work was last done by yourself (here). Could you take a quick look at the problem and proposed solution and add any context you might have / thoughts about anything this could break...

@benjackwhite benjackwhite marked this pull request as ready for review August 25, 2022 07:45
@benjackwhite benjackwhite marked this pull request as draft August 25, 2022 10:30
@benjackwhite benjackwhite requested review from pauldambra and removed request for timgl and pauldambra August 25, 2022 17:21
benjackwhite and others added 10 commits September 5, 2022 10:20
# Conflicts:
#	posthog/api/test/test_persons_trends.py
#	posthog/queries/trends/breakdown.py
#	posthog/queries/trends/total_volume.py
# Conflicts:
#	ee/clickhouse/queries/test/test_event_query.py
#	ee/clickhouse/queries/test/test_trends.py
#	posthog/api/test/test_persons_trends.py
#	posthog/queries/test/test_trends.py
@posthog-bot
Copy link
Contributor

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week.

@posthog-bot
Copy link
Contributor

This PR was closed due to lack of activity. Feel free to reopen if it's still relevant.

@posthog-bot posthog-bot closed this Dec 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants