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

abstracting datetime boilerplate #8770

Closed

Conversation

gregology
Copy link

@gregology gregology commented Oct 4, 2023

resolves #

Problem

It takes a lot of Jinja boilerplate to generate datetime objects.

{% set foo = modules.datetime.datetime(1997, 9, 29, 6, 14, tzinfo=modules.pytz.timezone('UTC')) %}

Solution

The PR introduces date() and datetime() macros to reduce boilerplate and increase code readability.

{% set foo = datetime(1997, 9, 29, 6, 14) %}

The datetime() macro defaults to UTC as is common in data warehouse applications.

Checklist

  • I have read the contributing guide and understand what's expected of me
  • I have run this code in development and it appears to resolve the stated issue
  • This PR includes tests, or tests are not required/relevant for this PR
  • This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc) or this PR has already received feedback and approval from Product or DX
  • This PR includes type annotations for new and modified functions

@gregology gregology requested a review from a team as a code owner October 4, 2023 18:20
@cla-bot
Copy link

cla-bot bot commented Oct 4, 2023

Thanks for your pull request, and welcome to our community! We require contributors to sign our Contributor License Agreement and we don't seem to have your signature on file. Check out this article for more information on why we have a CLA.

In order for us to review and merge your code, please submit the Individual Contributor License Agreement form attached above above. If you have questions about the CLA, or if you believe you've received this message in error, please reach out through a comment on this PR.

CLA has not been signed by users: @gregology

@github-actions
Copy link
Contributor

github-actions bot commented Oct 4, 2023

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

@gregology gregology requested a review from a team as a code owner October 4, 2023 18:38
@gregology gregology requested a review from emmyoop October 4, 2023 18:38
@cla-bot cla-bot bot added the cla:yes label Oct 4, 2023
@gregology gregology force-pushed the abstracting_datetime_boilerplate branch from 8ed0bc6 to 28d1006 Compare October 4, 2023 18:43
@gregology gregology force-pushed the abstracting_datetime_boilerplate branch from 28d1006 to b6b2f57 Compare October 4, 2023 18:44
@dbeatty10
Copy link
Contributor

@gregology that is a nice reduction in number of characters (~30 characters vs. ~84)! 🤩

This looks like a great candidate for inclusion within a dbt package. dbt_date is a popular one that comes to mind. It is automatically included within the dbt_expectations package as well.

Another option is to publish your own dbt package and host it on the dbt Package Hub.

We're going to hold off on adding these convenience macros to dbt-core in favor of distribution via the package ecosystem instead. So I'm going to close this as "not planned".

But please let us know in this thread if you end up adding this to a package!

@dbeatty10 dbeatty10 closed this Oct 9, 2023
@dbeatty10 dbeatty10 added the wontfix Not a bug or out of scope for dbt-core label Oct 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla:yes wontfix Not a bug or out of scope for dbt-core
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants