I would urge you to re-read Robert Elz's comments, and spend a day
contemplating the consequences of this change. He did a much better job
explaining the concerns I have about this.
I read it, and I understood and agreed with his concerns about the symbolic
timezone names. But I didn't agree with his concerns about the displayed
time, and the way he handles times in email is completely contrary to the way
I do. Which is fair enough; to each his or her own.
But ultimately, I think this change is ill thought out and should not be
applied. Popular (by vote) ideas are not necessarily the correct ones.
Sigh. Well, here's the thing ... popular vote at least captures what
the majority of people actually want. Even Robert admitted, "There is no
one right answer". I'm fine to go against popular vote when it comes to
RFC compliance, but this is really about what is displayed for people who
haven't changed the defaults. It sure seems like popular vote is a fair
way to capture the sentiment here.
For people who actually use dates (as Robert also pointed out), this
change destroys the point of using local TZ information in the header.
Otherwise, we would just normalize the date headers to UTC everywhere.
If people want things converted to local time, let them make the change
in their profiles. Maybe we need an easier format verb to simplify the
process – I certainly would not argue against that.
Let's turn that around; why shouldn't people who want the original date
header displayed have to change their defaults? That's assuming that
any of the people currently advocating that are still running with a
stock mhl.format and scan format; I doubt that's the case.
FWIW, I did try coming up with something like the existing (hidden) exmh
code, the best I could do is:
%<(nodate{text})%{text}%|%(pretty{text})%(void(szone{text}))%<(eq 1) (Local:
%(date2local{text})%(day{text}) (hour{text}):%(min{text}))%>%>
There is no way of getting the symbolic name of the local timezone out
because there's not a format escape which generates that. Also, if
you just want to create that extra info if the timezone is different
from your local one, limitations in the format engine prevent you from
checking if that is the case. We could probably do with a few more
format escapes; I'll think about that.
I could be persuaded to have the default display both (origin timezone
and local timezone, a la exmh). Robert indicated he's be fine with
that, and that might keep everyone happy (or at least less grumpy).
Regardless, all options should be documented in mhl.format so it's
easy for users to pick whatever they want without having to parse
mh-format(5). Of course, that's just for show ... even Robert admitted
scan is a bit tougher.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers