[CT-2558] [Feature] Make `run_started_at` an aware Python datetime
- Dominant language
- Rust
- Stars
- 13.8k
- Forks
- 2.6k
- Avg merge
- 21h 31m
- Merged PRs (30d)
- 56
Description
### Is this your first time submitting a feature request?
- [X] I have read the [expectations for open source contributors](https://docs.getdbt.com/docs/contributing/oss-expectations)
- [X] I have searched the existing issues, and I could not find an existing issue for this feature
- [X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion
### Describe the feature
In the following source code, we can see how [`run_started_at`](https://docs.getdbt.com/reference/dbt-jinja-functions/run_started_at) is a **naive**(!) Python datetime representing the current time in UTC:
- https://github.com/dbt-labs/dbt-core/blob/dffbb6a659177cdfd2330816e8cd0e6be2293dee/core/dbt/context/base.py#L565
- https://github.com/dbt-labs/dbt-core/blob/dffbb6a659177cdfd2330816e8cd0e6be2293dee/core/dbt/tracking.py#L118
- https://github.com/dbt-labs/dbt-core/blob/dffbb6a659177cdfd2330816e8cd0e6be2293dee/core/dbt/tracking.py#L453
So that the `run_started_at` can be compared unambiguously with aware timestamps, it should probably be aware as well with one of the two approaches:
1. `dt.now(timezone.utc).isoformat()` (offset from UTC)
1. `dt.now().astimezone().isoformat()` (offset from system time zone)
There's a good summary [here](https://github.com/dbt-labs/dbt-core/issues/5267#issuecomment-1513306428) of dbt Python datetimes.
But regardless of `deprecation_date` for dbt model versions, the fact that it's naive is tech debt that we should pay down, IMO by upgrading `run_started_at` to an aware timestamp with UTC offset of +00:00.
### Describe alternatives you've considered
The most obvious alternative is to leave it as-is (if it's not broke, don't fix it, right?).
I actually don't know if "fixing" this would have any unintended consequences for folks using it like either of these examples:
```sql
select
'{{ run_started_at.strftime("%Y-%m-%d") }}' as date_day
from ...
```
```sql
select
'{{ run_started_at.astimezone(modules.pytz.timezone("America/New_York")) }}' as run_started_est
from ...
```
I would _hope_ that it wouldn't break in either of those cases, but I didn't try them out one way or the other.
### Who will this benefit?
One place this could come into play is here:
- https://github.com/dbt-labs/dbt-core/pull/7562#issuecomment-1540961640
### Are you interested in contributing this feature?
_No response_
### Anything else?
_No response_
Contributor guide
Assessment
This issue has not been assessed yet.