From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nathan_Lynch@mentor.com (Nathan Lynch)
Date: Wed, 26 Oct 2016 11:29:37 -0500
Subject: [lttng-dev] [RFC/PATCH 3/3] babeltrace: add simple tests for
 converter command line options
In-Reply-To: <1311701030.5606.1477488992406.JavaMail.zimbra@efficios.com>
References: <1477409667-8309-1-git-send-email-nathan_lynch@mentor.com>
 <1477409667-8309-4-git-send-email-nathan_lynch@mentor.com>
 <cf84fcde-92c8-e3fc-90ff-a2dda72d037f@gydle.com>
 <1311701030.5606.1477488992406.JavaMail.zimbra@efficios.com>
Message-ID: <3a353056-a549-b626-fce4-cb09fe11c934@mentor.com>

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?