Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timestamps should all be in the same format #4

Open
rhaist opened this issue Feb 13, 2017 · 2 comments
Open

Timestamps should all be in the same format #4

rhaist opened this issue Feb 13, 2017 · 2 comments
Labels

Comments

@rhaist
Copy link

rhaist commented Feb 13, 2017

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

  1. unix timestamp format as string value (REF: Fields containing only numbers should be JSON integers #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 adulau added the valid label Oct 26, 2017
@adulau
Copy link
Member

adulau commented Oct 26, 2017

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
Copy link

sthagen commented Dec 12, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants