THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| name | description | type | default | valid values | importance |
|---|---|---|---|---|---|
unix.precision | The desired epoch precision for the timestamp. Used to generate the output when type=unix or used to parse the input if the input is a Long. Note: This SMT will cause precision loss during conversions from and to values with sub-milliseconds components. | String | millismilliseconds | , , , | low |
Proposed Changes
New config property for TimestampConverter
...
| Code Block | ||
|---|---|---|
| ||
"transforms.TimestampConverter.type": "org.apache.kafka.connect.transforms.TimestampConverter$Value", "transforms.TimestampConverter.field": "event_date_long", "transforms.TimestampConverter.unix.precision": "microsmicroseconds", "transforms.TimestampConverter.target.type": "Timestamp" |
...
| Code Block | ||
|---|---|---|
| ||
"transforms.TimestampConverter.type": "org.apache.kafka.connect.transforms.TimestampConverter$Value", "transforms.TimestampConverter.field": "event_date_str", "transforms.TimestampConverter.format": "yyyy-MM-dd'T'HH:mm:ss.SSS", "transforms.TimestampConverter.target.type": "unix", "transforms.TimestampConverter.unix.precision": "nanosnanoseconds" |
java.util.Date and SimpleDateFormat limitations
...
If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.
Name the field epoch.precision
Since epoch is not a measure but rather a point in time, it can't be associated to a precision.
It makes more sense to name the field unix.precision for that reason.
Use , , , or as values
seconds is a unit, but millis micros, nanos are really just prefixes. Mixing up doesn't work well.
s, ms, µs, ns are a valid SI symbols but the µs (or its accepted equivalent us) can be confusing.
For clarity, it was decided to use the plaintext naming convention.