change started_at ended_at to be timestamps

[bakerfranke]

Description

This PR casts the started_at and ended_at fields in int_school_years to be timestamps.

Directly from the seed file the were loaded as type varchar. This causes our use of these fields using date logic to incorrectly evaluate expressions using between because it's evaluating the dates as strings. What's moderately crazy is that this only effects exact date matches. For example:

SELECT
*
FROM int_school_years
WHERE '2023-07-01' between started_at and ended_at;

Returns null. But...(change the date July 2)....

SELECT
*
FROM int_school_years
WHERE '2023-07-02' between started_at and ended_at;

returns the expected row.

This can all be solved/fixed by casting started_at and ended_at as dates/timestamps.

The original analysis.school_years used timestamps so we will here as well.

[allison-code-dot-org]

didn't realize these weren't timestamps already- good catch!

[jordan-springer]

Suggested change

	school_year::varchar,
	school_year::varchar(7),

[jordan-springer]

Suggested change

	school_year_long::varchar
	school_year_long::varchar(9)

[jordan-springer]

LGTM-- my only thought is to maintain precision here for school_year and school_year_long and to make sure we test the timestamp changes resolves what was called out above and doesn't adversely affect anything upstream in dbt

[jordan-springer]

Description

This PR casts the started_at and ended_at fields in int_school_years to be timestamps.

Directly from the seed file the were loaded as type varchar. This causes our use of these fields using date logic to incorrectly evaluate expressions using between because it's evaluating the dates as strings. What's moderately crazy is that this only effects exact date matches. For example:

SELECT
*
FROM int_school_years
WHERE '2023-07-01' between started_at and ended_at;

Returns null. @bakerfranke but this should return null?...
But...(change the date July 2)....

SELECT
*
FROM int_school_years
WHERE '2023-07-02' between started_at and ended_at;

returns the expected row.

This can all be solved/fixed by casting started_at and ended_at as dates/timestamps.

The original analysis.school_years used timestamps so we will here as well.

[jordan-springer]

let's huddle about this date/timestamps thiing but this is fine.