Ken Hornstein <kenh(_at_)cmf(_dot_)nrl(_dot_)navy(_dot_)mil> writes:
If you think that it's _that_ important to have correct date handling for
non-standard timezones that don't even seem to be used anymore ...
They are still used. I still get mail from Japanese colleagues with the JST
timezone. I'm sure I could find current instances of the other
no-longer-functioning zones as well, if I looked for them.
You mean, without a timezone offset? (+0900, or whatever Japan is). If
it's in parenthesis, it's just a comment, so it shouldn't matter. I
haven't seen any mail from the people I know in Japan without a proper
timezone offset in a long time.
Yes, without a timezone offset. I have a bunch of these from my company's
Japanese customer. Also found one in a recent (March 2002) post on the
Bugtraq mailing list (I can't point you to the online archived copy because
the archive parses the dates and re-states them relative to one's own
timezone), and elsewhere.
And in any case, in that old mail on the subject that I forwarded yesterday,
I gave an instance where the textual timezone was apparently being used in
preference to the numeric one (in a case where both appeared), and because
the textual timezone was being interpreted incorrectly, the whole date was
coming out wrong. Until this is fixed, you can't depend on the presence of
numeric offsets to make sure dates are correctly interpreted.
I'm more concerned about nmh not handling current mail,
As well you should be. But the two are not mutually exclusive.
and an informal survey I did of my inbox showed that with
the exception of spam I haven't seen a malformed Date header in a while.
If there is lots of email out there that don't have timezone offsets in
the Date header, I'd be interested in hearing about it.
I can run another check like my last one, when I get the time, to find
additional (non-spam) mails with dates that used to parse correctly but no
longer do with 1.0.4+dev.
other than to point out that opimizing nmh behavor for _old_ mail seems to
be self-defeating.
Who said anything about *optimizing* it for old mail? I just want it to
still work properly on old mail. I don't think a small increase in
portability is worth removing long-standing and important functionality.
I guess we have different definitions of "work properly", "small increase",
and "important functionality". Oh well.
Again, I don't understand why you're making such a big deal of this. If I
find the functionality important and want to spend time implementing it once
we have a new working CVS repository, more power to me, no? As long as
parsing of RFC-compliant dates is not broken in the midst of restoring the
ability to parse the non-compliant ones, I don't see what possible objection
you can have.
Are you perhaps making such a big deal of it because you feel my desire to
retain the old date-parsing ability is responsible for 1.0.5 (and possibly
even successors to it) not being out right now? I can tell you, that's not
the case. On the last project I was on at work (something like a year
long), I was simply too busy to work on nmh or other open source packages I
contribute to. Most of the time I wasn't even caught up on my nmh-workers
mail, so if people had said, "Alright, screw the date-parsing lossage, let's
go ahead and release 1.0.5 now," I wouldn't even have been around to
object. And as I said in my other post, once the 1.0.5 release had lagged
for a long time, I *wouldn't* have objected to a release anyway.
--
Dan Harkless
nmh(_at_)harkless(_dot_)org
http://harkless.org/dan/