Fix/timestamp withought timezone

[fivetran-joemarkiewicz]

This is a:

• bug fix PR with no breaking changes — please ensure the base branch is main
• new functionality — please ensure the base branch is the latest dev/ branch
• a breaking change — please ensure the base branch is the latest dev/ branch

Description & motivation

I have noticed a few of the users of Fivetran dbt packages that are using Redshift have experienced errors in their dbt runs within the dateadd or datediff macros. I was able to identify the issue being caused by the timestamp in the customers Redshift instance is of type timestamp_tz. The error then occurs because the timestamp_tz and timestamp do not play well together. Here is an issue from our Jira package where the issue is occurring.

Database Error in model jira__issue_enhanced (models/jira__issue_enhanced.sql)
  function pg_catalog.date_diff("unknown", timestamp with time zone, timestamp with time zone) does not exist
  HINT:  No function matches the given name and argument types. You may need to add explicit type casts.
  compiled SQL at target/run/jira/models/jira__issue_enhanced.sql
Encountered an error:
FailFast Error in model jira__issue_enhanced (models/jira__issue_enhanced.sql)
  Failing early due to test failure or runtime error

Understanding this, I tried to leverage the dbt_utils.type_timestamp macro, but found it didn't convert the timestamp_tz to timestamp. After doing more research, I found that in Redshift you need to explicitly identify the datatype as timestamp without time zone in order for the conversion to be accurate.

I wanted to open this PR because I felt it would help other dbt_utils users who may experience this weird nuance in Redshift if their time data is synced as timestamp_tz as this will cause. Additionally, I saw you set the snowflake timestamp as timestamp_ntz so I felt it would fit well here!

Finally, I felt that since this was a Redshift issue, it may also be possibly occurring with Postgres? Therefore, I added only a Postgres config, and since Redshift picks up Postgres configs I felt this would be the best way. Happy to change this if that is not the case.

I did test this on an instance where the data is not synced as timestamp_tz and found the macro still worked as intended. Let me know if you have any question on this proposed change. Thanks!

Also last bit: when opening the PR I noticed the instructions still ask to point to master. I just updated to main since the rename.

Checklist

• I have verified that these changes work locally on the following warehouses (Note: it's okay if you do not have access to all warehouses, this helps us understand what has been covered)
  • BigQuery
  • Postgres
  • Redshift
  • Snowflake
• I followed guidelines to ensure that my changes will work on "non-core" adapters by:
  • dispatching any new macro(s) so non-core adapters can also use them (e.g. the star() source)
  • using the limit_zero() macro in place of the literal string: limit 0
  • using dbt_utils.type_* macros instead of explicit datatypes (e.g. dbt_utils.type_timestamp() instead of TIMESTAMP
• I have updated the README.md (if applicable)
• I have added tests & descriptions to my models (and macros if applicable)
• I have added an entry to CHANGELOG.md

[joellabes]

Thanks for the detailed writeup @fivetran-joemarkiewicz, and for taking me on the journey with you! I agree with your conclusions around prior art (Snowflake's behaviour) and that PGSQL and Redshift are likely to behave the same.

I've also had a look at existing type_timestamp calls in utils, and don't see any that assume a timezone. Happy to merge this!