-
Notifications
You must be signed in to change notification settings - Fork 527
Add a datediff implementation for postgres #187
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
Hi, so sorry about the delay here, kicking off the tests now! I think they might actually fail as we have two concurrent test suits running, but I'll re-trigger the tests if they do fail |
The tests almost passed! I'd be happy to not have a I'm going to take a look at the code now as well :) |
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.
Given that Snowflake doesn't support decade
and I suspect century
and millenium
, let's remove them from this implementation and the tests. Other than that, it's LGTM!
macros/cross_db_utils/datediff.sql
Outdated
{% elif datepart == 'day' %} | ||
(({{second_date}})::date - ({{first_date}})::date) | ||
{% elif datepart == 'week' %} | ||
({{ dbt_utils.datediff(first_date, second_date, 'day') }} / 7 + case when date_part('dow', ({{second_date}})::timestamp) < date_part('dow', ({{first_date}})::timestamp) then 1 else 0 end) |
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.
I've spent far longer than I'd like to admit deciphering this line (and am still left scratching my head). Fortunately, I've tested it pretty thoroughly and I'm convinced it works 👍
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.
OK so I found a bit of weirdness. If you do a datediff between:
- First date: Tuesday 4th Feb 2020
- Second date: Monday 3rd Feb 2020 (yes a prior day)
Then the result is1
, whereas I think the result should be 0.
This is certainly a strange edge case, so I'm not super concerned here. But wanted to flag it just in case. I'm happy to merge it as is though!
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.
Ugh, you're right. Thanks for catching that. Turns out postgres rounds toward 0 in integer division instead of always down (but casting from double
to integer
rounds down; I expected the opposite behavior).
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.
I'm so glad you know what's happening here ha. I truly had no idea!
This is my version of the fix
|
Since postgres rounds integer division toward 0, we should treat positive and negative date differences distinctly
Week calculation tests are more about correctness than parsing, so belong in the seed data.
I've kicked off the tests but won't have time to review this properly until later this week 😅 |
first_date and second_date need to be compared in sql instead of jinja, as their values are going to come from the sql data.
@clrcrl No worries. The tests picked up something I missed anyway. Thanks for kicking those off! |
|
This PR adds a
datediff
implementation for PostgreSQL, and updates the integration tests to exercise the various types of date parts the implementation covers.