hi Richard, your email was hard to follow, and I don't have real answers for you but maybe my simpleton's view of the situation might offer you new avenues of thought to consider. Richard Lynch wrote: > It's been 20+ years since I took a stats class... 20 years ago I was mostly riding a push bike ... and I've never taken a stats class as such (bare this in mind :-) > > I didn't enjoy that class, and doubt if I remember 1% of what was > covered. you'd be 1 up on me ;-) > ... > > And the sheer number of functions in the stats package is making my > head spin. > ... > > Some fools have their PC clock set to, like, 1970 or whatever. So > let's be generous and assume their CMOS battery has died, and they > haven't had a chance to change it. Fine. Deal with it. > > Okay, so *NOW* the algorithm is to do this: > > Take the Date: header, or Sent: header if no Date: header -> $whatdate > > Parse the Received: headers for the MTA date-stamps -> $fromdates[] > > Compare the values in $fromdates array with $whatdate. > > If the variance is "too high", then ignore the $whatdate, and take > the, errr, first?, average?, $fromdates[]. does it matter so long as your consistent in what you pick/use/calculate? I would tend to go for the oldest date in any given array of processed dates as this would seem to be the closest to the likely actual send date. > > No, wait, maybe I should do a variance within the $fromdates in case > some stupid MTA server has a bad clock? I would start by setting out a few acceptable boundaries and 'knowns' for instance: 1. the first mail was sent no earlier than timestampX (so any timestamp encountered that is earlier than this is bogus.) 2. a maximum time an email could be expected to hang out at any given MTA whilst waiting to be moved on. (could be used to drop an outer timestamps [oldest & newest] from a given array of timestamps extracted from mail whose difference is to it's 'neighbour' is greater than this agreed maximum period.) > > Any advice? 1. don't forget to normalize all found dates in a given mails array of dates into UTC (if that is even an issue) before doing any actual processing/analysis of the collected dates. 2. I would consider the date's found in the Date: and/or Sent: headers with the same brush as any dates found in the Recieved headers - your explanation suggest than no one header could be construed as being more reliable than another. 3. er there is no 3, unless you consider 'buy a bigger brain' real advice ;-) > > Anybody got a good "variance" function to do what I'm trying to do? > > Am I on the entirely wrong path here? dunno - but it's another typical Lynch problem that was just too interesting for me to let slide :-) please do keep us posted as to your progress! > Sheesh! > > We may just ignore any obviously wrong dates, and process those by > hand... indeed anything that is blatantly 'dodgy' with regard to dates is probably easier to (and more accurately) processed by hand than it is to create some wizzo algo. for it - it's a matter of getting the number of 'dodgy' down to an acceptable level of course. > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
