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
To conform with standard API marshaling and unmarshaling the timestamps should all be formated conform with RFC 3339 (https://tools.ietf.org/html/rfc3339)
The text was updated successfully, but these errors were encountered:
It's a single field at the event level and indeed, it's not very nice. This change is significant as we need an upgrade script on MISP for old data. We keep it open until we fix on the MISP core.
I took part in quite some discussions on JSON serialization of time and I cannot say, that this was always joyful or enlightening ;-) even when as in this case, no timezone variation in the datasets are allowed which really eases temporal discussions.
For the sake of deciding on a way to go forward, maybe one should consider the priorities of the modeling and "ownership" per field?
On one hand:
If the timestamp typed string fields are mostly of interest to the producers that already have these Unix EPOC "at hand", and consumers mostly care for the date fields on day granularity (say for filtering / paging / sorting) and directly digestable as-is by human readers, then it could well be preferable to just keep it the way it is.
... on the other hand:
If primary navigation / indexing is a primary value, then maybe even using numbers for both field types could boost processing speed if needed and allow for scaling insert, update, and select like operations.
After all these are not fields in packets of a network protocol, but serialization of very high-level data, where the communities use cases should IMO rule the domain types.
The current RFC for misp-core-format has two different timstamp formatings:
To conform with standard API marshaling and unmarshaling the timestamps should all be formated conform with RFC 3339 (https://tools.ietf.org/html/rfc3339)
The text was updated successfully, but these errors were encountered: