dbt-labs / dbt-labs/dbt

[CT-2558] [Feature] Make `run_started_at` an aware Python datetime

Open
#7,581 1 comment 0 reactions 0 assignees View on GitHub
engine:v1 type:feature type:tech-debt
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.