[JB] * MHonArc should understand most non-numeric timezones. May need some education. Logs show MHonArc is ignorant of AEST, MET; no errors reported under fukuzawa. See <TIMEZONE> resource.
[AL] <TIMEZONE> does not list JST for Japan in the defaults - seems to be US only. But Japanese MUAs may avoid using JST and usually be set as numeric since much other software also tends to be US timezone abbreviations only. No error message suggests next most likely cause is misset clocks/timezones, specifically no time zone at all (which might be taken as GMT and produce approx 17 hour offset from Japan?). Any light shed by checking the date fields of the wrongly sequenced messages? [JB] * A single clock incorrectly set far in the future can do very large damage. More than enough to offset the gains of Date: indexing. [AL] Not understood. Wouldn't it just result in messages from that 1 computer going to the top of the index, becoming very noticeable as they pile up there and resulting in email from users who notice that to the sender suggesting a clock reset? -- Leaving aside that you have buried the sender's address in HTML comments (discussed in separate message) [JB] * Agree, a multi-index solution may be a good way to go for medium term. (If benefit outweighs cost) [AL] Computer resource cost should be small - just space for extra date indexes and index pages which would be low in comparison to messages and text indexes, with little extra processing. Main cost would be time it takes someone who has already figured out MHonArc rcfiles to use the facility for extra indexes ;-) [JB] * This is the type of issue the relational database folks love (like www.reference.com) where they can let the archive viewer decide stuff like this. [AL] Looks like a useful site, thanks for the pointer. (Not as elegantly simple for adding a list: http://www.reference.com/cgi-bin/pn/go.py?choice=mlistsuggestform and does not seem to provide for adding old messages at all).
