Sender has no dateColumn() setter for DATE columns

从 Sender 现有的 byteColumn、charColumn、timestampColumn、ipv4Column、at 和 atNow 实现开始，以遵循既有的 setter 约定。使用毫秒和建议的 Instant 重载添加 DATE 支持，确认预期的亚毫秒行为，并验证 Java ingestion 能够写入 DATE 值，同时保留 null 行为。

Summary

Sender has no dateColumn() setter, so a Java producer cannot write a DATE column — even though the server accepts DATE on QWP ingress and this client reads it back fine on egress.

Current status: documented as a limitation

The client documentation already concedes it — documentation/connect/clients/java.md:532:

DATE is accepted on ingress server-side but the Java client does not yet expose a dateColumn() setter. All types are readable on the egress side.

Cross-client parity

DATE is the only type missing from Java's row-oriented ingestion API, and Java is the only QWP client missing DATE:

Sibling implementations, all taking milliseconds since epoch:

• Rust — column_date(name, millis: i64) and column_date_opt (questdb-rs/src/ingress/buffer.rs:1393, :1418)
• C — line_sender_buffer_column_date (include/questdb/ingress/line_sender.h:1086)
• Go — DateColumn(name string, val time.Time) QwpSender (qwp_sender.go:61)
• .NET — ColumnDate(name, long millisSinceEpoch)

Suggested shape

Matching the existing setter conventions on Sender (byteColumn, charColumn, timestampColumn, ipv4Column, …):

Sender dateColumn(CharSequence name, long millisSinceEpoch);
Sender dateColumn(CharSequence name, Instant value);

The long overload mirrors the other clients' wire-level form; the Instant overload matches how timestampColumn(name, Instant) already reads at the call site. As with every other column, a null is written by omitting the setter before at() / atNow().

Worth confirming the intended truncation behaviour for the Instant overload, since DATE is millisecond-resolution and Instant is not — silently truncating sub-millisecond precision versus rejecting it is a deliberate choice, and the other clients sidestep it by only accepting millis (except Go, which takes a time.Time).