Time filters

[Rafael Barbosa]

Did some quick tests and it seems that everything works in version 3.0.3.15:
$./ra -D5 -t  2009/01/22.00-2009/01/22.23
ra[20791.20cc2670ff7f0000]: 15:58:35.724971 ArgusParseTime (0x512000,
0x512108, 0x7026e960,2009,  , 0.000004) retn 1232578800: 1606413180
ra[20791.20cc2670ff7f0000]: 15:58:35.725100 ArgusParseTime (0x512000,
0x512140, 0x512108,2009, -, 0.000004) retn 1232661600: 1606413176
ra[20791.20cc2670ff7f0000]: 15:58:35.728315 ArgusCheckTimeFormat
(0x7026e960, 2009/01/22.00-2009/01/22.23) retn 0:
1232578800.000000-1232661600.000000
ra[20791.20cc2670ff7f0000]: 15:58:35.728330 ArgusParseTimeArg
(2009/01/22.00-2009/01/22.23, 4, 0x7026e960)

$./ra -D5 -t  2009/01/22
ra[20787.20cc2670ff7f0000]: 15:57:08.660057 ArgusParseTime (0x512000,
0x512108, 0x512140,2009,  , 0.000003) retn 1232578800: 1606413212
ra[20787.20cc2670ff7f0000]: 15:57:08.660308 ArgusCheckTimeFormat
(0x7026e960, 2009/01/22) retn 0: 1232578800.000000-1232665200.000000
ra[20787.20cc2670ff7f0000]: 15:57:08.660443 ArgusParseTimeArg (2009/01/22,
4, 0x7026e960)
ra[20787.20cc2670ff7f0000]: 15:57:08.660922 ArgusAddFileList (0x512000, -,
1, -1, -1) returning 1

And in my system:
$date -r 1232578800
Thu Jan 22 00:00:00 CET 2009
$date -r 1232661600
Thu Jan 22 23:00:00 CET 2009
$date -r 1232665200
Fri Jan 23 00:00:00 CET 2009

I still did not have the time to replot the graphs. However, as the time
ranges are being decoded correctly, I expect everything to be OK. I will
report back if I have any further problems with these time filters.

Thanks,
Rafael


On Tue, Jul 13, 2010 at 9:47 AM, Rafael Barbosa <rrbarbosa at gmail.com> wrote:

> I will install this version and report the results better today. Regarding
> the summer time, yes we do have it, from the last Sunday of March to the
> last Sunday of October.
>
> Rafael
>
> On Tue, Jul 13, 2010 at 4:11 AM, Carter Bullard <carter at qosient.com>wrote:
>
>> Hey Rafael
>> The new argus-clients-3.0.3.15 fixes this problem.  Please
>> give this a try on your machine to see if you don't see a correction.
>>
>>    http://qosient.com/argus/dev/argus-clients-3.0.3.15.tar.gz
>>
>> Carter
>>
>>  On Jul 12, 2010, at 11:08 AM, Rafael Barbosa wrote:
>>
>> Ok. Let me try answer all questions:
>>
>>
>> When I convert your range for Jan 22, 2009, using
>>
>> "date -r 1232492400" and "date -r 1232578800", I get the range:
>>
>>
>>>    Tue Jan 20 18:00:00 EST 2009 - Wed Jan 21 18:00:00 EST 2009
>>
>>
>>> Do you get similar results on your system?
>>
>>
>> I get a different range, by the way, I am using a MacOS X 10.6.4:
>> $ date -r 1232492400
>> Wed Jan 21 00:00:00 CET 2009
>> $ date -r 1232578800
>> Thu Jan 22 00:00:00 CET 2009
>>
>> Does this mean ra is checking the day 21 instead of 22 in my system?
>>
>> Where are you located and what timezone is your system using?
>>
>>
>> Enschede, NL - Central European Timezone (CET)
>>
>> Are you using the RA_TZ variable in your raTime.conf file? What string are
>>> you using there?
>>
>> No.
>> $ cat raTime.conf
>> RA_TIME_FORMAT="%F_%H:%M"
>>
>> What range does your client show when you use the times that do work?
>>>    ra -D5 -t  2009/01/22.00-2009/01/22.23
>>>
>> ra[9394.20cc2670ff7f0000]: 16:47:54.678576 ArgusCheckTimeFormat
>> (0x7026e960, 2009/01/22.00-2009/01/22.23) retn 0: 1232492400-1232661600
>>
>> And how does your system interpret those time ranges?
>>
>> Wed Jan 21 00:00:00 CET 2009 - Thu Jan 22 23:00:00 CET 2009
>>
>> My understanding is that the filter "2009/01/22" is checking day 21 in my
>> system while  "2009/01/22.00-2009/01/22.23" include all flows from day 21
>> until 23h at day 22. Is that correct?
>>
>> Best regards,
>> Rafael
>>
>> ps.: In my timezone is 5pm now, so I probably can only reply to a follow
>> up message tomorrow...
>>
>>
>>
>>  Carter Bullard
>> CEO/President
>> QoSient, LLC
>> 150 E 57th Street Suite 12D
>> New York, New York  10022
>>
>> +1 212 588-9133 Phone
>> +1 212 588-9134 Fax
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100713/2dc4c6f2/attachment.html>