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
|
