search

MISP / misp-rfc

Specifications used in the MISP project including MISP core format
46 stars 18 forks source link

Timestamps should all be in the same format #4

Open rhaist opened 7 years ago

rhaist commented 7 years ago

The current RFC for misp-core-format has two different timstamp formatings:

  1. unix timestamp format as string value (REF: #3)
  2. date as YYYY-MM-DD

To conform with standard API marshaling and unmarshaling the timestamps should all be formated conform with RFC 3339 (https://tools.ietf.org/html/rfc3339)

adulau commented 7 years ago

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.

sthagen commented 6 years ago

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.