LISTSERV needs a date for every message that it processes. Without a date, it cannot show messages in chronological order, perform a search by date range, and so on. This is such a vital requirement that LISTSERV will generate a date field if there isn't one in the message (of course, Internet standards require every message to have to valid date field, but I have seen quite a few messages with no date field at all). RFC822 specifies the one and only allowable format for a date field in an e-mail message. Unfortunately, many mail clients do not follow this format. What they produce usually looks somewhat similar from a distance, but it is not the same thing, especially to computer. When the format is incorrect, LISTSERV uses heuristics to try and figure it out anyway, and then rewrites it correctly to guarantee that every subscriber's mail client will "see" the same date for that message (badly broken dates are also known to crash certain mail clients, sometimes requiring very delicate technical work before the mail client will start again, and we don't want LISTSERV to be involved in that kind of problem, since by definition problems like these are always the fault of the company with the smallest legal department, and that would definitely be us). There is no way to correctly understand all possible formats, because they conflict with each other. For instance, some mail clients will supply the date as 08/01/05, while others use 01/08/05 or 05/08/01. Some supply the time as 1812, but this could be the year too (well, maybe not 1812, but certainly 2005, which could be 8.05pm as well). This is a big mess in which you will find all kinds of digits in all kinds of possible orders and vague clues about what looks like it might be this or that. When you see the three letters GMT, though, you know you can depend on having found your time zone. For all the broken date fields I have seen since 1986, not once have I seen GMT mean something other than Greenwich Mean Time. Of course, if GMT is the time zone, you no longer need to consider whether the remaining elements could be a time zone. I have to say that double time zones are a new phenomenon. I can try to improve blackberry recognition, but frankly, I hate having to mess with this code, because every time I improve recognition of a new incorrect format, I create a problem with another incorrect format that was working just fine before. In fact, I ended up deleting half of the heuristics about 10 years ago and simply inserting the server's current date and time when the date field is all too "creative." Currently, LISTSERV only attempts to fix dates that do not look all too different from the norm. The only good solution is for every mail client to implement RFC822 date format. This format dates back from 1982, it is easy to read and easy to program, frankly there is no excuse for doing things differently! Eric