[Bug]: ISODate serialization truncates millisecond precision

[pilis]

Related Template(s)

mongodb_to_bigquery

Template Version

2026-02-03-00_rc01

What happened?

I have MongoDB to BigQuery dataflow job.

When there are ISODate (example: ISODate('2026-02-03T15:31:41.924Z')) in Mongo documents, then in BigQuery those appear in descriptive (long) format like "Feb 3, 2026, 3:31:41 PM".

This error is related to how "Read Documents" transforms MongoDB Documents to JSON here: https://github.com/GoogleCloudPlatform/DataflowTemplates/blob/main/v2/mongodb-to-googlecloud/src/main/java/com/google/cloud/teleport/v2/transforms/JavascriptDocumentTransformer.java#L150

By default it uses Relaxed JSON mode: https://github.com/mongodb/mongo-java-driver/blob/main/bson/src/main/org/bson/Document.java#L418

Gemini suggested that:

If JsonWriterSettings aren't explicitly forced to ISO-8601, the MongoDB Java driver defaults to "Relaxed" mode. In this mode, it uses the JVM's default Locale to stringify dates.
Locale.US produces: Feb 3, 2026, 3:31:41 PM
ISO Standard would be: 2026-02-03T15:31:41.924Z

Could someone take a look at this?

Relevant log output

[tvalentyn]

@pilis thanks for reporting.

1. If we changed the datetime format to preserve this precision, would it be an improvement for all users or potentially a breaking change for some users?

2. Since you took a look, do you have a potential fix in mind, and if so would you be open to potentially contribute it? Thanks!

[pilis]

1. This change is not backward compatible because the date format will change from Long to ISO. This is a downstream problem for consumers of this data. I think this can be handled with a flag that would switch the parsing of this JSON to another mode (if that's a solution).
2. At the moment, I've managed to find a potential root cause. I've reported this bug with the hope that someone knows how to fix it faster; if not, I'll probably tackle it myself (although I'm not a Java programmer)