I’m against adding this. We can already express this using the current format.

@varnerac actually no, we can not. 2018-01-01T00:00:00.001Z for example is in fact a real time that someone might want to query on.

Sorry. Hit wrong button and closed.

I read this too quickly. I think this warrants a new predicate to express version ranges, rather than deviating from the current timestampdata type.

But for this field value, we do not define it as needing to be a timestamp type since some object types other than STIX might have a different version field.

Well, non-STIX content has the option of using any string for the query string. However, version "requests a specific version of an object". That's not suitable for a range request, which returns multiple versions. Your "starts with" syntax is just a range request. It makes an assumption that people want to search on ranges that correspond with the timestamp string's prefix. Why not provide an explicit range operator?

I'd prefer explicit range operators rather than override version to handle a specific version or range of versions via a string prefix comparison.

For what it's worth, the "TAXII Information Request and Response" proposal addresses this use case.

you can use ISO 8601 Time Intervals: https://en.wikipedia.org/wiki/ISO_8601#Time_intervals These are computers, calculating time intervals are easy, and they can fully fill out the time. People should not be generating query strings/parameters by hand by themselves, their client should be.