I'm using

elementary-data==0.23.2

with

dbt-fusion 2.0.0-preview.173

on BigQuery. On Linux/Docker, dbt-fusion writes nanosecond precision timestamps to `run_results.json`:

"completed_at":"2026-05-05T08:03:17.243625708Z"

This is 9 decimal digits. BigQuery

TIMESTAMP

only supports 6 (microseconds), and

edr

fails when processing these values. On macOS the same dbt-fusion version writes identical nanosecond timestamps to

run_results.json

, but

edr

works fine there. Question: Where exactly in the

edr

Python code does it parse

execute_completed_at

/

completed_at

from

run_results.json

or from BigQuery? Is there a known workaround to truncate nanoseconds to microseconds before

edr

processes them? Or does Elementary sanitize these timestamp strings before inserting into BigQuery? Clock resolution confirmed:

time.clock_getres(CLOCK_REALTIME)

=

1e-09

on Linux. Python

3.11.15

on Linux,

3.11.6

on Mac. Same

elementary-data

version on both.

BigQuery Nanosecond Timestamp Issue with Elementary + dbt-fusion This is a known issue. Starting with

dbt-bigquery >= 1.11

(and reproduced with

dbt-fusion

), nanosecond-precision timestamps (9 fractional digits, e.g.

2026-05-05T08:03:17.243625708Z

) appear in

execute_completed_at

from

run_results.json

. BigQuery's

TIMESTAMP

type only supports microsecond precision (6 digits), so

CAST(... AS TIMESTAMP)

fails with

Invalid timestamp

errors — completely blocking

edr report

and

edr send-report

. [BigQuery timestamp fix] Why macOS vs Linux behaves differently The knowledge sources do not explicitly explain the macOS vs Linux behavioral difference. However, the root cause is confirmed:

dbt-fusion

writes 9-digit fractional timestamps, and Elementary's processing of those values fails on BigQuery. [BigQuery timestamp fix] The Fix: Two PRs were merged into the Elementary dbt package 1.

normalize_artifact_timestamp_precision

macro — normalizes precision for

execute_started_at

,

execute_completed_at

,

compile_started_at

, and

compile_completed_at

fields when writing to

upload_run_results.sql

and

upload_source_freshness.sql

. [BigQuery artifacts fix] 2.

bigquery__edr_cast_as_timestamp

dispatch macro — truncates fractional seconds beyond 6 digits before casting string values to

TIMESTAMP

. [BigQuery timestamp fix] Workaround: Add the macro to your own dbt project Since dbt prioritizes project-level macros over package macros, you can add this macro to your own

macros/

directory (e.g.,

macros/edr_cast_as_timestamp.sql

) to override the default behavior without modifying the Elementary package:

{% macro bigquery__edr_cast_as_timestamp(column) %}
    cast(
        regexp_replace({{ column }}, r'(\.\d{6})\d+', '\\1')
        as timestamp
    )
{% endmacro %}

This uses

regexp_replace

to truncate any fractional seconds beyond 6 digits before casting to

TIMESTAMP

. Timestamps with ≤6 fractional digits or no fractional seconds pass through unchanged. [BigQuery timestamp fix] Recommendation The primary recommendation is to upgrade your

elementary-data/elementary

dbt package to the latest version that includes both fixes. The knowledge sources do not explicitly confirm whether version

0.23.0

already includes these fixes, so checking for a newer release is advised. [BigQuery timestamp fix] > Note: The knowledge sources do not detail the specific Python-side

edr

code path that parses

completed_at

from

run_results.json

. The fixes described above are at the dbt macro/SQL layer, not the Python layer. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.