Apparant insect in date processing ...

[Peter Van Epp]

	We are in Standard time at the point of the processing and the record
is on daylight. The end time seems to figure that out, but the start time 
doesnt' (i.e. the end time was 06:30 as it should have been). I also haven't
tried this with 2.0.6 input but I'd guess it will do the same thing.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada


On Thu, Nov 06, 2003 at 10:09:23AM -0500, Carter Bullard wrote:
> Hey Peter,
>    Sorry for the delayed response.  Yea, the man record conversion
> needs a bit of work, but you know, not many 1.8.1 argi running
> around out there ;)
> 
>    So, does this go over the boundary of daylight savings,
> or is it that we are in daylight savings, and the record is not?
> 
> Carter
> 
> 
> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu
> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of Peter Van Epp
> Sent: Monday, November 03, 2003 12:20 AM
> To: argus-info at lists.andrew.cmu.edu
> Subject: Apparant insect in date processing ...
> 
> 
> 	 Left with too much time on my hands I have found an apparant bug in
> argus-2.0.beta.13 (and I expect clients.beta.47) in time processing. I had
> occassion to ranonymize 7 days of data for someone, then attempted to select
> an 06:30 to 06:30 slice out of the 7 days of data. There being a time change
> between now and then, something looks to have broken on the starting time
> extract (but not the end). The initial file is 1.8.1 data but it is being
> processed by 2.0.6 binarys:
> 
> ra -r oct1-7.argus.gz -t 10/01.06:30-10/02.06:30 -w oct1-2
> 
> this should extract Oct 1 06:30 til Oct 2 06:30 however it does extract
> Oct 01 07:30 til Oct 2 06:30 (I verified that it really is the 07:30 data
> in the original unanonymized file). I'd guess a daylight flag is being
> misinterpreted (or outright missed) on the start time parse but not the end
> time (since both times are from before the last time change here).
> 
> ra -r oct1-2 -nn > t
> 
> %head t
> 01 Oct 03 00:00:03    man version=1.8     probeid=16777472
> STA
> 01 Oct 03 07:30:00      6     197.0.39.87.29101  ->        197.0.7.52.1423
> RST
> 01 Oct 03 07:30:00     17    197.0.33.229.33366 <->         100.0.1.2.53
> ACC
> 01 Oct 03 07:30:00      6       100.0.1.9.48206  ->        1.0.14.202.113
> RST
> 01 Oct 03 07:30:00     17   100.0.187.101.59541 <->         100.0.1.2.53
> ACC
> 01 Oct 03 07:20:15      0       197.0.5.2       <->           1.0.7.2
> CON
> ...
> %tail t
> 02 Oct 03 06:29:59      1    197.0.13.236        ->       197.0.24.59
> ECO
> 02 Oct 03 06:29:59      1     197.0.48.41        ->      100.0.16.243
> ECO
> 02 Oct 03 06:29:29      1      100.0.1.20       <->        197.0.10.1
> ECO
> 02 Oct 03 06:29:59      1     1.0.176.161        ->       197.0.23.78
> ECO
> 02 Oct 03 06:29:53      1    100.0.19.109        ->     197.0.202.112
> URFIL
> 02 Oct 03 06:29:52      1     100.0.15.39        ->     197.0.174.246
> URH
> 02 Oct 03 06:30:00      1      1.0.21.208        ->       100.0.35.34
> ECO
> 02 Oct 03 06:26:47      1     100.0.15.39        ->      197.0.75.189
> URH
> 02 Oct 03 06:30:00      1        1.0.27.6        ->      100.0.19.221
> ECO
> 02 Oct 03 00:00:04    man  pkts 300298335  bytes  -1914213615  drops
> -1073086464  STP
> 
> 	And of course the man line is extremely wrong. I keep meaning to
> look
> at that ...
> 
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
> 
>