Re: [cti] timestamp proposal for STIX 2.0 RC3

[Michael Chisholm <chisholm@mitre.org>]

As far as I was able to tell, the epoch isn't the problem (unless you're 
facing numeric range issues).  1/1/1970 midnight UTC is an unambiguous 
point in time afaik.  Therefore, a true elapsed time since that point, 
measured in fixed-duration TAI/UTC seconds, is also unambiguous.  The 
problem seems to be with some implementations/specifications saying 
"don't count the leap seconds" (e.g. POSIX).  That appears to take the 
true elapsed time, snips out some little pieces of it, and you add up 
the larger pieces that remain.  That "elapsed time" is then a little bit 
off.

For the year/month/day/hour/minute/second representation, there's also 
the question of whether the "seconds" field can ever be 60 (or skip over 
59?).  But if you choose not to represent timestamps that way, it's a 
moot point.

Whether an inaccurate "elapsed time" would cause any problems probably 
depends on what you need to do with the timestamps.  You'd probably know 
that better than I.

Andy

On 12/2/2016 8:58 AM, Wunder, John A. wrote:
> I support option 1. I also think JMG is probably right that we should pick a particular epoch definition but I don’t know what the right one would be.
>
> On 12/2/16, 8:55 AM, "cti@lists.oasis-open.org on behalf of Kirillov, Ivan A." <cti@lists.oasis-open.org on behalf of ikirillov@mitre.org> wrote:
>
>     I support option #1 as well.
>
>     Regards,
>     Ivan
>
>     On 12/2/16, 4:06 AM, "cti@lists.oasis-open.org on behalf of Mr. Stefan Hagen" <cti@lists.oasis-open.org on behalf of stefan@hagen.link> wrote:
>
>         On 01.12.2016 22:19:27, Allan Thomson wrote:
>         >
>         > Proposal #1 is the preferred approach but including 2 options for
>         > consideration to see if others have a different preference.
>
>         I support option #1:
>         JSON Number format, UNIX Epoch with an optional fractional component, separated by the decimal character "."
>
>         All the best at 1480676728.022066t,
>         Stefan.