(CC to the mhonarc list since this may be important for other
users)
Huan,
I'm going to tell you what changed between 2.0b3 to 2.0 regarding
date processing, and also how mhonarc in general handles some
cases. This may help explains things and save some time for
both of us in solving the problem.
First, the diffs between 2.0b3 to 2.0:
The main thing here is the following bug fix:
Version: 2.0.0 beta 3
Problem: Numerical timezone offsets not handled properly
when the offset contained non-zero minutes. This
caused message to be sorted wrong by date.
Solution: Fixed.
Version Fixed: 2.0.0
I noticed that some of the dates you provided, there are non-zero
minutes in the offset value. Therefore, under 2.0b3 (and all previous
versions), it did *not* sort the date properly. This is fixed in 2.0
and minutes are handled correctly. This should explain why the changes
in location of sendmail generated messages between versions. I hope
this alone may explain the change in ordering.
Second, if no timezone is specified in a date, MHonArc assumes
local time.
To really verify if the order of the messages are correct, you must
examine the dates and take the offset/timezone in affect. If no
timezone/offset exists, you must use your local offset from GMT to
determine the "real" time. I.e. For each date, you apply the
offset/timezone then compare to see which date is newer, or older.
If you can, ignore 2.0b3 results since they are invalid since
you have dates with non-zero minutes in the time offset value.
Take the results of a 2.0 run, and see if it really did the right
thing.
Another thing to look at after a 2.0 run is to examine the
.mhonarc.db file and the %Date hash. The key for each message
is actually the following:
mhonarc-computed-unix-time(a-separator-char)message-num
Look at the unix time and see if it is valid with respect to
the other dates (and its own).
*NOTE*: Because you have a pre-2.0 created archive (including 1.x
versions), the sendmail-based messages (ie. any message with a non-zero
minute specification in the hour offset from GMT) archived will always
get sorted incorrectly according to date since MHonArc does not
recompute the unix time after a message is in the archive. For
performance reasons, mhonarc uses part of the index key for the message
to do date sorting. Only a complete recreation of the archive with 2.0
will fix the problem.
If all of this does not explain the behavior you are seeing, or you
believe an error is still occuring, please provide a test case (data
and invocation) that is simplest as possible so I can quickly determine
the cause. It could take me some time to try to do something
with what you have given so far, but I would not be confident that
could adequately find a cause (if one existed).
Hope this helps,
--ewh
P.S. The date generated by your CGI should be handled correctly.
At least it recognizes it since you get no errors stating
mhonarc could not parse date.
