[lttng-dev] [RFC/PATCH 3/3] babeltrace: add simple tests for converter command line options

[Nathan_Lynch@mentor.com (Nathan Lynch)]

On 10/26/2016 08:36 AM, Mathieu Desnoyers wrote:
> ----- On Oct 26, 2016, at 3:11 AM, Sebastien Boisvert sboisvert at gydle.com wrote:
> 
>> Hi Nathan,
>>
>>> diff --git a/tests/bin/test_clock_seconds b/tests/bin/test_clock_seconds
>>> +# [s]+.[nnnnnnnnn]
>>> +timestamp_fmt="\["
>>> +timestamp_fmt+="[[:digit:]]+" # [s]+
>>> +timestamp_fmt+="\."
>>> +timestamp_fmt+="[[:digit:]]{9}" # [nnnnnnnnn]
>>> +timestamp_fmt+="\]"
>>> +
>>
>>
>> Is the timestamp 0.123456789 possible ?
>>
>> Is there a minimum for the left part, something like Epoch ?
> 
> We can also have slightly negative timestamps due to support of
> non-GMT timezones. A timezone with a negative offset from GMT with
> an offset 0 (a trace which appears to be taken exactly at epoch)
> ends up at the very end of Dec 31, 1969. It can be represented
> with a negative timestamp with the s.ns notation.
> 
> This mainly happen when a system boots without network connectivity
> and think it is exactly at Epoch. Not that uncommon unfortunately.

I hadn't really intended to make the regexes in these tests rigorous
beyond what was required for the wk-heartbeat-u sample trace but I
suppose I could do so.  Sample traces for this kind of case would be
helpful.

Alternatively, I could test verbatim (no regexes) against the output of:

$ TZ='' babeltrace --clock-seconds \
   tests/ctf-traces/succeed/wk-heartbeat-u

Which should be stable across systems, no?