Because the crawl.log timestamps are the 'fetch
completed time' for a completed CrawlURI, and different
CrawlURIs take different amounts of time to finish
post-fetch steps, the timestamps in the crawl.log are
not in strict order.
This is by design, but confusing. An alternate
end-of-processing timestamp could be used for the
crawl.log that ensures expected ever-increasing
timestamps.
If Igor and Dan don't find anything useful about the
end-of-fetch time as opposed to end-of-processing, we
should switch to end-of-processing time.
Since the crawl.log timestamp is already different from
the ARC record timestamp (crawl.log uses end-of-fetch;
arc-record uses start-of-fetch), there shouldn't be any
other loss of consistency/cross-referenceability.
Gordon Mohr
Usability/UI
None
Public
|
Date: 2007-03-14 00:18
|
|
Date: 2005-03-03 07:46 Logged In: YES |
|
Date: 2005-03-03 04:09 Logged In: YES |
|
Date: 2005-03-02 19:40 Logged In: YES |
|
Date: 2005-02-03 23:05 Logged In: YES |
| Field | Old Value | Date | By |
|---|---|---|---|
| status_id | Open | 2005-03-03 07:46 | gojomo |
| resolution_id | None | 2005-03-03 07:46 | gojomo |
| close_date | - | 2005-03-03 07:46 | gojomo |
| assigned_to | nobody | 2005-03-02 19:40 | gojomo |
| priority | 6 | 2005-02-10 00:55 | stack-sf |
| priority | 5 | 2005-02-03 23:05 | stack-sf |
Copyright © 2010 Geeknet, Inc. All rights reserved. Terms of Use