Re: [Nmh-workers] date math

Lyndon Nerenberg writes: > On Dec 15, 2014, at 9:46 AM, Ken Hornstein wrote: > >> So that makes me wonder if >> we should still try to bother to generate a symbolic timezone name. It >> looks like the only portable way to do this is to have an internal list >> of timezone names. A large part o

Re: [Nmh-workers] date math

David Levine writes: > Ken wrote: > >> >[Norm:] >> >Shouldn't that be the default? >> >> You know ... maybe? What do others think? > > No, because date is the sender's context. And it's easy enough > to change how it's viewed. Disagree, because the date is viewed in the reader's context. Easy

Re: [Nmh-workers] date math

>That's fine, but there actually is a wrong answer - and that's losing >info with no easy way to recover it. Sigh. My point is that the information is not "lost" ... it's still there! We just choose not to display it! Users can still get it if they want! It's just that it seems like a majority

Re: [Nmh-workers] date math

Date:Mon, 15 Dec 2014 21:47:23 -0500 From:Ken Hornstein Message-ID: <201412160247.sbg2lnvp013...@hedwig.cmf.nrl.navy.mil> | Sigh. Well, here's the thing ... popular vote at least captures what | the majority of people actually want. Even Robert admitted, "There

Re: [Nmh-workers] date math

>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

Re: [Nmh-workers] date math

>It does, it just had a bug for + zones (as you will have >seen from my previous message). Fair enough ... I see the problem. That setting is NOT EXPOSED ANYWHERE! You have to know about it. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.or

Re: [Nmh-workers] date math

> Lyndon Nerenberg > Monday, December 15, 2014 6:12 PM > > ... > > 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. +1.

Re: [Nmh-workers] date math

Date:Mon, 15 Dec 2014 20:07:41 -0500 From:Ken Hornstein Message-ID: <201412160107.sbg17gfq012...@hedwig.cmf.nrl.navy.mil> | > Date: Mon, 15 Dec 2014 12:56:46 -0500 (Tue 00:56 ICT) | | That ... does not seem to be something that exmh does, actually, at | lea

Re: [Nmh-workers] date math

On Dec 15, 2014, at 5:57 PM, Ken Hornstein wrote: > FWIW, in a rough survey of people who have chimed in on this issue, a > significant majority are in the "Local Time Now!" camp. So unless others > wish to make their case, I'm going to make that the default. But I think > Jerrad's suggestion

[Nmh-workers] exmh patch to fix local time display in date header

Following on some discussions on the nmh list, I observed a problem with the local time display in exmh (which is doing what I think should be the default for nmh - that is, displaying both th original (sender) Date: header with the local time appended. Except that it wasn't working in the case th

Re: [Nmh-workers] date math

FWIW, in a rough survey of people who have chimed in on this issue, a significant majority are in the "Local Time Now!" camp. So unless others wish to make their case, I'm going to make that the default. But I think Jerrad's suggestion about including the alternative, commented out, in all of the

Re: [Nmh-workers] date math

>> In the EST/CDT division, existing routines already "know" if a >> particular date falls under DST so there is no ambiguity there. But >> like you said, it's hard to know if the sender is in the "wrong" >> hemisphere :-) > >Do they get Saskatchewan right? (I haven't looked at the code. I don't

Re: [Nmh-workers] date math

On Dec 15, 2014, at 5:23 PM, Ken Hornstein wrote: > Note that I was only suggesting that the timezone be displayed at the > local side, and although I didn't mention it I was only going to suggest > it support IETF-sanctioned timezones. But it seems like there's little > political will for that

Re: [Nmh-workers] date math

On Dec 15, 2014, at 5:07 PM, Ken Hornstein wrote: > In the EST/CDT division, existing routines already "know" if a > particular date falls under DST so there is no ambiguity there. But > like you said, it's hard to know if the sender is in the "wrong" > hemisphere :-) Do they get Saskatchewan

Re: [Nmh-workers] date math

>The IETF has been discouraging symbolic timezone names for many years. >I would say ditch them. For those who want a symbolic timezone (usually >recipients) it's so they can easily mentally convert to their local >time. Those folks are better served by a + offset that their local >MUA can un

Re: [Nmh-workers] date math

>It actually is hard, there's no one-one mapping between numeric offsets >and timezone names.abbreviations - you alo need to know the origin of the >message (of course, if you've converted to local time, and are just >printing the local offset, then it is relatively easy). > >For example, if you se

Re: [Nmh-workers] date math

On Dec 15, 2014, at 9:46 AM, Ken Hornstein wrote: > So that makes me wonder if > we should still try to bother to generate a symbolic timezone name. It > looks like the only portable way to do this is to have an internal list > of timezone names. A large part of me says to not bother. The IET

Re: [Nmh-workers] date math

On Dec 15, 2014, at 9:23 AM, n...@dad.org wrote: > Shouldn't that be the default? I like it the way it is. I correspond with people all over the planet, and I find it very helpful to know their local time when they send a message. It provides a very strong hint as to whether I can expect a q

Re: [Nmh-workers] date math

robert wrote: > Date:Mon, 15 Dec 2014 15:39:44 -0500 > From:hy...@lactose.homelinux.net > Message-ID: > > | Now you're comparing content to metadata. > > Not really, I was certainly not suggesting doing anything with the > content of the message (though I'm

Re: [Nmh-workers] date math

Date:Mon, 15 Dec 2014 15:39:44 -0500 From:hy...@lactose.homelinux.net Message-ID: | Now you're comparing content to metadata. Not really, I was certainly not suggesting doing anything with the content of the message (though I'm not sure about encapsulated messages)

Re: [Nmh-workers] date math

Robert Elz writes: >You might care about both - the "how long ago was it sent" type of use >needs local, the "please reply before 7pm", or "I need a reply business hours >today" type of use needs the sender's timezone (and perhaps the local one >as well). Now you're comparing content to metadata.

Re: [Nmh-workers] date math

Date:Mon, 15 Dec 2014 13:14:14 -0500 From:Ken Hornstein Message-ID: <201412151814.sbfiee96007...@hedwig.cmf.nrl.navy.mil> | I dunno ... I mean, do you care about the date an email was sent _in the | sender's timezone_? Or do you care about the date an email was s

Re: [Nmh-workers] date math

Date:Mon, 15 Dec 2014 12:56:46 -0500 From:Ken Hornstein Message-ID: <201412151756.sbfhukow007...@hedwig.cmf.nrl.navy.mil> | It's actually not hard ... you'd have a table to convert a numeric offset | to a symbolic one, with two entries (one for regular, one for DS

Re: [Nmh-workers] date math

hy...@lactose.homelinux.net writes: > Just to provide a data point, I want to look at the email and easily say > "Oh, it was sent two hours ago." And the easiest way to do that is to have > the date formatted in my local (or at least, my preferred) time zone. > > It doesn't matter to me that it

Re: [Nmh-workers] date math

First off, thank you for the original info -- that was exactly what I wanted. Ken Hornstein writes: >I dunno ... I mean, do you care about the date an email was sent _in the >sender's timezone_? Or do you care about the date an email was sent >in _your_ timezone? Now that I think about it, I rea

Re: [Nmh-workers] date math

>> >[Norm:] >> >Shouldn't that be the default? >> >> You know ... maybe? What do others think? > >No, because date is the sender's context. And it's easy enough >to change how it's viewed. I dunno ... I mean, do you care about the date an email was sent _in the sender's timezone_? Or do you car

Re: [Nmh-workers] date math

>i'd prefer symbolic, but i understand that it's probably complicated to >get right. It's actually not hard ... you'd have a table to convert a numeric offset to a symbolic one, with two entries (one for regular, one for DST). It's just ... should we bother? --Ken __

Re: [Nmh-workers] date math

ken wrote: > You know ... as long as we're on this subject. > > I see that there is no longer any difference between the %(tws) and > %(pretty) escape, since David Levine removed the backend code that > differentiated this in commit 0c926c599d9def7f70. Because it didn't > work (it would ret

Re: [Nmh-workers] date math

I would suggest local date as the default is sensible, if someone wants the raw date they can view the file directly. However, either way it goes, the alternative should be included in the default format file but commented out and with an explanation, since mh-format is not intuitive for all and ne

Re: [Nmh-workers] date math

You know ... as long as we're on this subject. I see that there is no longer any difference between the %(tws) and %(pretty) escape, since David Levine removed the backend code that differentiated this in commit 0c926c599d9def7f70. Because it didn't work (it would return the local timezone symbol

Re: [Nmh-workers] date math

Ken wrote: > >[Norm:] > >Shouldn't that be the default? > > You know ... maybe? What do others think? No, because date is the sender's context. And it's easy enough to change how it's viewed. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org

Re: [Nmh-workers] date math

Hi Ken, > > Shouldn't that be the default? > > You know ... maybe? What do others think? Yes. scan listings too. All the dates! I thought the same just after sending my other email and was waiting for more activity so I could reply with the suggestion. :-) If I'm on a machine that doesn't

Re: [Nmh-workers] date math

Hi Ken, > For this case, you'd want: > > Date:formatfield="%<(nodate{text})%{text}%|%(date2local{text})%(pretty{text})%>" I use date2local and do datefield,formatfield="... to have it apply to all date fields. I use it in some scan listings too. Cheers, Ralph. __

Re: [Nmh-workers] date math

>Shouldn't that be the default? You know ... maybe? What do others think? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] date math

Ken Hornstein writes: >>So my wife's employer's hosted email system is set up in UTC. Every >>the email I get from her includes a header line such as >> >>Date: Mon, 15 Dec 2014 16:27:12 + >> >>It's probably outside the scope of NMH, but I was hoping there might >>be a way to set up "show" or

Re: [Nmh-workers] date math

>So my wife's employer's hosted email system is set up in UTC. Every >the email I get from her includes a header line such as > >Date: Mon, 15 Dec 2014 16:27:12 + > >It's probably outside the scope of NMH, but I was hoping there might >be a way to set up "show" or "mhl" to notice this and conv

[Nmh-workers] date math

So my wife's employer's hosted email system is set up in UTC. Every the email I get from her includes a header line such as Date: Mon, 15 Dec 2014 16:27:12 + It's probably outside the scope of NMH, but I was hoping there might be a way to set up "show" or "mhl" to notice this and convert the