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
We discussed this at length on the cti-stix list and came to the following requirements:
Timestamps MUST follow RFC 3339 with the following extra requirements
Timestamps MUST use the timezone offset
Timestamps MUST use the following format yyyy-mm-ddThh:mm:ss.mmmmmm+-hh:mm
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".
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.
The text was updated successfully, but these errors were encountered:
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.
We discussed this at length on the cti-stix list and came to the following requirements:
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.
The text was updated successfully, but these errors were encountered: