You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some feeds only provide timestamps as duration past midnight, assuming prior context of what day the processed messages are from. Since the messages themselves don't have this context, it would be useful to be able to append a statically specified date, convert that to Unix milliseconds, and append it as a manufactured int field to outbound messages. This would reduce friction for downstream SQL analytics on messages ingested from these feeds.
Good point, now with handlers being somewhat configurable, this could possibly just become a TimestampHandler with several modes: e.g.: pull forward from Seconds message, append static date, manufacture single timestamp column from a nanos timestamp + date, etc.
Algorithmically, normalizing dates from low-context streams (messages providing only nanos past midnight, e.g.) might look something like:
Some feeds only provide timestamps as duration past midnight, assuming prior context of what day the processed messages are from. Since the messages themselves don't have this context, it would be useful to be able to append a statically specified date, convert that to Unix milliseconds, and append it as a manufactured
int
field to outbound messages. This would reduce friction for downstream SQL analytics on messages ingested from these feeds.e.g
--message_handlers AppendDateHandler:date=20291102
would turn that date into it's UNIX seconds equivalent, and append that as column to all outbound messages.
The text was updated successfully, but these errors were encountered: