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

STIX should mandate a single timestamp format #85

Open
johnwunder opened this issue Dec 3, 2015 · 1 comment
Open

STIX should mandate a single timestamp format #85

johnwunder opened this issue Dec 3, 2015 · 1 comment

Comments

@johnwunder
Copy link
Member

We discussed this at length on the cti-stix list and came to the following requirements:

  1. Timestamps MUST follow RFC 3339 with the following extra requirements
  2. Timestamps MUST use the timezone offset
  3. Timestamps MUST use the following format yyyy-mm-ddThh:mm:ss.mmmmmm+-hh:mm
  4. There will be an optional precision field (timestamp-precision) with the following string values: year, month, day, hour, minute, second, millisecond, microsecond. If precision is omitted, the default value of precision is "microsecond".
  5. When using the precision field, unknown values MUST be zeroed out

Some of those requirements may be superseded by data types in serialization formats (particularly binary formats) but as much as possible all serializations will follow these rules.

@packet-rat
Copy link

Requirement 1 above implies that we can address our stated concerns with representations of patterns and events on 1-10 Gbs Networks, modern CPU Clocks, etc.,(and extend as technology advances to higher and higher speeds...at least up to Planck Time: 10E-43 ;-)

RFC 3339 specifies fractional seconds in ABNF as [time-secfrac = "." 1DIGIT]. This "" notation means any level of DIGITS/Precision required.

We believe this is the correct approach: use the precision one requires (for the use case at hand) using the representations available in the referenced Normative Standards.

If this is not the case, we respectfully request the opportunity (at some future date) to revisit the requirement to represent Time in the actual time-scales the systems and events we are describing operate.

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

No branches or pull requests

2 participants