Skip to content

Map DateTime to google.protobuf.Timestamp and document temporal string formats#1306

Open
jwils wants to merge 1 commit into
joshuaw/proto-field-numbersfrom
joshuaw/proto-timestamp
Open

Map DateTime to google.protobuf.Timestamp and document temporal string formats#1306
jwils wants to merge 1 commit into
joshuaw/proto-field-numbersfrom
joshuaw/proto-timestamp

Conversation

@jwils

@jwils jwils commented Jul 9, 2026

Copy link
Copy Markdown
Collaborator

Why

Mapping DateTime to string loses the type safety proto offers — a string can be malformed in ways a google.protobuf.Timestamp cannot, and proto consumers get language-native timestamp types. For the remaining string-typed temporal scalars, the proto type is much wider than the ElasticGraph type, so the expected format deserves documentation at the point of use (per review discussion).

What

  • Map DateTime to google.protobuf.Timestamp, importing google/protobuf/timestamp.proto automatically. A Timestamp is a UTC instant, so a publisher's original UTC offset is not preserved; t.protobuf type: "string" remains available as an override.
  • t.protobuf gains two options usable by any scalar:
    • import: maps a scalar to an externally defined proto type, emitting the needed import statement
    • comment: documents the expected format on each generated field
  • The built-in string-typed temporal scalars (Date, LocalTime, TimeZone) use comment: to document their formats (e.g. // ISO 8601 date, e.g. "2024-11-25"). Values are still validated at ingestion time, exactly as with JSON ingestion.
  • Format comments compose with the existing source name: comments and propagate to the innermost nested-list wrapper field.

Risk Assessment

Low — only affects the unreleased elasticgraph-proto_ingestion extension from #1080.

References

…g formats

`DateTime` fields now use the well-known `google.protobuf.Timestamp` type
(with `google/protobuf/timestamp.proto` imported automatically) instead of
`string`. A Timestamp cannot be malformed the way a string can, and proto
consumers get language-native timestamp types. Note that a Timestamp is a
UTC instant, so a publisher's original UTC offset is not preserved;
`t.protobuf type: "string"` remains available to override.

To support this, `t.protobuf` gains two options usable by any scalar:

- `import:` maps a scalar to an externally defined proto type, emitting the
  needed `import` statement in `schema.proto`.
- `comment:` documents the expected format on each generated field, used by
  the built-in `string`-typed temporal scalars (`Date`, `LocalTime`,
  `TimeZone`) whose proto type is wider than the ElasticGraph type (e.g.
  `// ISO 8601 date`). Values are still validated at ingestion time, just
  as with JSON ingestion.
@jwils jwils force-pushed the joshuaw/proto-field-numbers branch from 90e2af5 to 616dbfd Compare July 9, 2026 18:13
@jwils jwils force-pushed the joshuaw/proto-timestamp branch from 1537869 to 721fe97 Compare July 9, 2026 18:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant