Open ryanmeekins opened 1 year ago
Thanks for opening this issue. I have a feeling this belongs over in dbt-date
since that's where the date math is actually being done, but try to I'll take a look next week. These sorts of things are typically hard to track down.
In the meantime, you could use row_condition
to filter out the offending hour.
Is this a new bug in dbt-expectations?
Current Behavior
The
expect_row_values_to_have_data_for_every_n_datepart
test when usingdate_part
set tohour
has test failures during the DST spring forward shifts, such as2022-03-13T02:00:00
. This isn't an actual hour for theAmerica/New_York
time zone. This hour is skipped as the time zone shifts, going from2022-03-13T01:00:00-05:00
to2022-03-13T03:00:00-04:00
.I suspect this is because the UTC offset isn't being used for
timestamp_tz
date columns.Expected Behavior
This test shouldn't fail on DST shifts, as long as each hour when converted to UTC or a single offset is there.
Steps To Reproduce
test_model
as:dbt build -s test_model
. The test should fail with 1 result. After inspecting, the row should be2022-03-13T02:00:00
.Relevant log output
Environment
Which database adapter are you using with dbt?
Snowflake: 1.3.0
Note: dbt-expectations currently does not support database adapters other than the ones listed below.
Additional Context