Repository: dbt-labs/dbt-core

Issue:
[CT-1645] [Regression] Datetime format in run_results.json results.timing[].completed_at has no timezone
### Is this a regression in a recent version of dbt-core?

- [X] I believe this is a regression in dbt-core functionality
- [X] I have searched the existing issues, and I could not find an existing issue for this regression

### Current Behavior

run_results.json and sources.json has completed_at datetime in timing report without timezone.

```
      "timing": [
        {
          "name": "compile",
          "started_at": "2022-12-09T11:45:25.274155Z",
          "completed_at": "2022-12-09T11:45:25.294915"
        },
        {
          "name": "execute",
          "started_at": "2022-12-09T11:45:25.312143Z",
          "completed_at": "2022-12-09T11:45:25.984434"
        }
      ],
```

### Expected/Previous Behavior

```
      "timing": [
        {
          "name": "compile",
          "started_at": "2022-12-09T11:45:25.274155Z",
          "completed_at": "2022-12-09T11:45:25.294915Z"
        },
        {
          "name": "execute",
          "started_at": "2022-12-09T11:45:25.312143Z",
          "completed_at": "2022-12-09T11:45:25.984434Z"
        }
      ],
```

### Steps To Reproduce

Happens on dbt Cloud with version 1.4.0a1

### Relevant log output

_No response_

### Environment

```markdown
dbt Cloud using HEAD version
- dbt (working version): 1.4.0a1 HEAD at 2022-12-07T15:45:32.039789Z
- dbt (regression version): 1.4.0a1 HEAD at 2022-12-07T16:01:21.330798Z
```


### Which database adapter are you using with dbt?

bigquery

### Additional Context

_No response_


Discussion:
Problem with timestamps, sometimes having timezone and sometimes not is also present in many dbt Cloud API endpoints.
@lustefaniak Thanks for reporting this!

I was able to reproduce this for `run_results.json` using dbt-core 1.4.0a1 (bigquery). I didn't try reproducing this for `sources.json`, but trust it is being rendered in a timezone-naive fashion as reported.

Agreed that `started_at` and `completed_at` should both be timezone-aware when rendered with an ISO 8601 format in `run_results.json`. Timestamps within `sources.json` should be timezone-aware as well.
Note that this issue resolves if mashumaro is rolled back to 3.1.1. I'm currently looking into workarounds and the option of going back to that version.
Related issue: https://github.com/Fatal1ty/mashumaro/issues/93
I got to the bottom of this issue in mashumaro and added my notes to the issue for them. Hopefully it will be enough information for them to fix it soon.

Resolving patch:
diff --git a/core/setup.py b/core/setup.py
--- a/core/setup.py
+++ b/core/setup.py
@@ -54,7 +54,7 @@
         "hologram>=0.0.14,<=0.0.15",
         "isodate>=0.6,<0.7",
         "logbook>=1.5,<1.6",
-        "mashumaro[msgpack]==3.2",
+        "mashumaro[msgpack]==3.3.1",
         "minimal-snowplow-tracker==0.0.2",
         "networkx>=2.3,<2.8.1;python_version<'3.8'",
         "networkx>=2.3,<3;python_version>='3.8'",


Test patch:
diff --git a/tests/unit/test_events.py b/tests/unit/test_events.py
--- a/tests/unit/test_events.py
+++ b/tests/unit/test_events.py
@@ -5,6 +5,7 @@
 from dbt.events.base_types import msg_from_base_event
 from dbt.events.types import *
 from dbt.events.test_types import *
+from dbt.contracts.results import TimingInfo
 
 from dbt.events.base_types import (
     BaseEvent,
@@ -464,3 +465,12 @@ def test_all_serializable(self):
 
 
 T = TypeVar("T")
+
+
+def test_date_serialization():
+    ti = TimingInfo("test")
+    ti.begin()
+    ti.end()
+    ti_dict = ti.to_dict()
+    assert ti_dict["started_at"].endswith("Z")
+    assert ti_dict["completed_at"].endswith("Z")