-
Logged In: YES
user_id=662545
You totally missed the point.
One of the records was 20020731232214, the next
20020801003421 . If you subtract 1000000 (which in the
current scheme would attempt to remove a day from the
timestamp) from the second, you get 20020800003421.
20020800003421 is still greater than 20020731232214. It's a
simple numeric comparison, right?
Therefore, it...
2002-12-11 18:08:25 UTC in AWStats
-
Logged In: YES
user_id=662545
Yeah, this is true. However, the problem is, it generates too
much inaccuracy.
For example, if a record dated 08/01/02 00:34:21 comes
before a record dated 07/31/02 23:22:14 (example times),
what does it do if you set
$NOTSORTEDRECORDTOLERANCE to 1000000?
The existing date formats would be 20020801003421 and
20020731232214. 20020801003421 -...
2002-12-09 16:02:40 UTC in AWStats
-
Logged In: YES
user_id=662545
I'm almost done with a fix... just got to track down a
slight inconsistency. I also adjusted all the default
time-based variables to use seconds.
Should be done and working by Monday. Well, actually, it
better be done by Monday, because I have to have it running
for customers on Monday :)
Also, I'm doing this against 5.2, since I couldn't get CVS
to...
2002-12-07 04:35:11 UTC in AWStats
-
Unless I'm reading the code wrong, in 2004 AWStats
will invalidate any data on Feb 29th.
From sub DateIsValid():
if ($month==2) {
if ($day > 28) { return 0; }
}.
2002-12-06 23:03:41 UTC in AWStats
-
As referenced <a
href="http://sourceforge.net/tracker/?func=detail&aid=648827&group_id=13764&atid=363764">here</a>,
the current method of handling internal dates and times
produces inaccuracies (sometimes up to 20% of the
logfile is "corrupted", when it shouldn't be considered
so). As I said, I am working on a fix, but it will
most likely...
2002-12-06 15:17:50 UTC in AWStats
-
Is anyone working on changing the way dates are handled in the
awstats code?
I know this is a pretty radical change. But unfortunately, for my
application, the existing method (converting everything to a
YYYYMMDDHHMMSS 14 digit string) isn't going to work. And,
IMO, it introduces unnecessary inaccuracies.
My big impetus for suggesting this is the following snippet from
trying...
2002-12-05 06:12:36 UTC in AWStats
