Client
The civil.DateTime type is unsuitable for use with BigQuery DATETIME.
These types are advertised for use with BigQuery, e.g.
|
// This type exists to represent the TIME type in storage-based APIs like BigQuery. |
|
// Most operations on Times are unlikely to be meaningful. Prefer the DateTime type. |
|
type Time struct { |
Environment
BigQuery data transfer service ingesting newline-delimited JSON in GCS into BigQuery.
Go Environment
Go 1.18
Code
The relevant code is where we want to use civil.DateTime for a field type so that we get the appropriate JSON encoding for BigQuery to ingest the field as DATETIME:
type Record struct {
...
StartedAt *civil.DateTime `json:"startedAt,omitempty"`
FinishedAt *civil.DateTime `json:"finishedAt,omitempty"`
...
}
Expected behavior
I would expect this type to serialize into a form compatible with DATETIME as described here, in particular:
[.F]: Up to six fractional digits (microsecond precision)
Actual behavior
Instead of microsecond precision, the types are encoded with nanosecond precision here:
|
return s + fmt.Sprintf(".%09d", t.Nanosecond) |
This results in errors like this when BigQuery attempts to ingest these as DATETIME:
Invalid datetime string "2022-07-23T02:37:52.032499000"
Field: start_time; Value: 2022-07-23T02:37:52.032499000
Client
The
civil.DateTimetype is unsuitable for use with BigQueryDATETIME.These types are advertised for use with BigQuery, e.g.
google-cloud-go/civil/civil.go
Lines 134 to 136 in a2ec33b
Environment
BigQuery data transfer service ingesting newline-delimited JSON in GCS into BigQuery.
Go Environment
Go 1.18
Code
The relevant code is where we want to use
civil.DateTimefor a field type so that we get the appropriate JSON encoding for BigQuery to ingest the field asDATETIME:Expected behavior
I would expect this type to serialize into a form compatible with
DATETIMEas described here, in particular:Actual behavior
Instead of microsecond precision, the types are encoded with nanosecond precision here:
google-cloud-go/civil/civil.go
Line 173 in a2ec33b
This results in errors like this when BigQuery attempts to ingest these as
DATETIME: