From: Tomi Ollila <tomi.ollila@iki.fi>
To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org
Subject: Re: [DRAFT PATCH] emacs: show local date next to Date: in case value
 differs
In-Reply-To: <87vbhf2zqk.fsf@maritornes.cs.unb.ca>
References: <1427132722-20346-1-git-send-email-tomi.ollila@iki.fi>
 <87vbhf2zqk.fsf@maritornes.cs.unb.ca>
User-Agent: Notmuch/0.19+107~gab55bdb (http://notmuchmail.org) Emacs/24.3.1
 (x86_64-unknown-linux-gnu)
Date: Tue, 07 Apr 2015 11:42:47 +0300
Message-ID: <m2y4m4z5vc.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

On Thu, Apr 02 2015, David Bremner <david@tethera.net> wrote:

> Tomi Ollila <tomi.ollila@iki.fi> writes:
>
>> When adding Date: header of a message to notmuch-show buffer, compare the
>> date string with local representation of it and if these differ, output
>> Date: {original-date-string}  ({local-date-representation})
>
> One thing I found confusing is that the local date representation is
> mostly redundant in the default configuration, as the date shown in the
> "headerline" is already in the local time zone if
> "notmuch-show-relative-dates" is t. From the fact that you made this
> patch I'm guessing that you don't use that setting.

I am using that setting...

Now I took a little better look why the 'relative' date is not enough for
me is that it doesn't always show the local date (it shows like 
(28 mins. ago) or (March 30)). If these were (28 mins. ago (07:22)) and
(March 30 16:20) then it would be better (w/ +0300 that might be marginally
more useful in general but perhaps something that can be lived without).

In this position where I am now I often get email from person residing
like 50 footsteps from me (in current tz +0300, yet the email server 
writes emails with tz -0500) Now if email was sent 28 minutes ago I cannot
immediately crasp what is that email in local time. Other similar effect
is when my old classmate puts a message to Facebook -- IIRC the timezones
of the notification emails there are -0700.
What makes this situation worse is that the notmuch-show buffer is showing
email arrived 28 mins. ago but the buffer has been sitting there for 2
hours while I've been doing something else; the relative date information
is not updated.
With (March 30) figuring out when that email was sent in local time is
harder as the granularity in relative date is 'one day'.

In IRC Jani mentioned it is feature to see the sender's TZ. I also consider
it as a feature. But also knowing the local time (quickly) is a feature to
me: An example: Someone(TM) sent email to a bunch of recipients yesterday
18:28 (that is 6.28 pm) from TZ -0500. Relative date showed that it was
sent (Today 02:28).
Just an hour ago we had a meeting where knowing that "half past 2" was
important information...

Based on this I start experimenting how I could "improve" the headerline
for my case -- so that in notmuch-show buffer the relative date has more
information. In notmuch-search buffer there is just not enough space.
Then I have to learn to look the headerline for this information...

Also, thanks to Mark for his comments of the implementation. Those will 
be useful at least in some other stuff I've planned to do...

> One option which would have the advantage not being as wide on the
> screen (Maybe my use case is strange, but I often use notmuch is 66
> column half screen-width terminals) would be to (optionally?) display
> the non-relative date in the headerline in the local time zone.

Before thinking how the "headerline" could be "improved" (for notmuch-show
buffer) I thought whether the local date could just show (hh:mm [+-]nnnn).
Also the comparison whether to show this additional info could be just
based on difference in timezone strings...

>> This is useful e.g. when mail system provides Date: strings with
>> different timezone information than the sender is located at.
>
> I'm not sure how local time information helps with the sender?  Unless
> you happen to be in the same time zone.

Yes, it would be exceptionally irritating someone living in different
timezone and the emails sent would show yet another timezone. Then seeing
local time would be more informational than the original Date:

>
> d

Tomi