VM

Translating dates to current time zone

Bug #930793 reported by Uday Reddy
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
VM
Triaged
Wishlist
John Hein

Bug Description

Alan Wehmann writes (2011-02-11, private email):

One thing of note is that in the summary buffer your message appeared
with the date and time shown in the Date header. In
Thunderbird, it made the adjustment for the time zone differences and
showed it with today's date, local time 6:43 p.m.

Tags: 7.19 summary
Revision history for this message
Uday Reddy (reddyuday) wrote :

Yes, there is no effort in VM to translate the date/time to the current time zone.

Do you not think it would be confusing to find one date in the summary buffer and another in the date header? Or do you think the Date header should be translated as well? (The latter would be harder to do.)

Revision history for this message
John Hein (xpqheqdvq4) wrote :

I've wanted something like this, too. The main thing for me is consistent presentation in the summary buffer (especially when looking at threaded conversations). Sorting by date is okay, but it'd be nice to allow all the times in the summary presented in a consistent time zone. Even forcing them all to UTC and ignoring TZ or local timezone settings would be okay (at least as an option).

For me, translating the date in the presentation of the message is less important. The OP may not feel the same. FWIW, Thunderbird does change the date in the message presentation to match the summary.

Revision history for this message
Alan Wehmann (alan-wehmann) wrote :

Here is an example of lines in the summary buffer (sorted by date) where the dates seemingly appear to be out of order:

   30 Uday S Reddy Feb 9 242/10962 "Re: 8.2.0b1"
   31 R Uday S Reddy Feb 10 16/687 "Re: 8.2.0b1"
-> 32 Alan Wehmann Feb 9 1734/125218 "more on 8.2.0b and Thunderbird INBOX folder"

From my *scratch* buffer the corresponding information is:

"date-1 is 2012020914:25:12, date-2 is 2012020914:25:12, month is February, day is 9, hour is 20:25:12
zone is +0000, parsed date is [ 14:25:12 ]
message-id is 4036, uidl is nil, author is Uday S Reddy"

"date-1 is 2012020918:43:28, date-2 is 2012020918:43:28, month is February, day is 10, hour is 00:43:28
zone is +0000, parsed date is [ 18:43:28 ]
message-id is 4037, uidl is nil, author is Uday S Reddy"

"date-1 is 2012020919:17:51, date-2 is 2012020919:17:51, month is February, day is 9, hour is 19:17:51
zone is -0600, parsed date is [ 19:17:51 ]
message-id is 4038, uidl is nil, author is Alan Wehmann"

so, the date sorting was correctly done

The above output is obtained from evaluating

(let ((aw-buf (get-buffer "XMAIL_vm Summary"))
      aw-msg aw-date-1 aw-date-2 aw-month aw-zone aw-day aw-hour aw-parse
      aw-msg-id aw-uidl aw-auth)
  (set-buffer aw-buf)
  (setq aw-msg (vm-current-message)
 aw-date-1 (vm-sortable-datestring-of aw-msg)
 aw-date-2 (vm-so-sortable-datestring aw-msg)
 aw-month (vm-month-of aw-msg)
 aw-zone (vm-zone-of aw-msg)
 aw-day (vm-monthday-of aw-msg)
 aw-hour (vm-hour-of aw-msg)
 aw-parse (vm-parse-date aw-date-1)
 aw-msg-id (vm-message-id-number-of aw-msg)
 aw-uidl (vm-pop-uidl-of aw-msg)
 aw-auth (vm-full-name-of aw-msg))
  (format (concat "date-1 is %s, date-2 is %s, month is %s, day is %s, "
    "hour is %s\nzone is %s, parsed date is %s\nmessage-id is %s, uidl is %s"
    ", author is %s")
   aw-date-1 aw-date-2 aw-month aw-day aw-hour aw-zone aw-parse aw-msg-id aw-uidl aw-auth))

on each message in turn

so, in principle, there is enough information available to make the summary buffer show a "local" timestamp (as Thunderbird apparenly does). I would not advocate changing the Date: header in the message itself.

Revision history for this message
Uday Reddy (reddyuday) wrote :

Hi John, are you volunteering to do this?

Changed in vm:
status: New → Triaged
milestone: none → 8.2.90a
Revision history for this message
John Hein (xpqheqdvq4) wrote :

Sure.

Changed in vm:
assignee: nobody → John Hein (xpqheqdvq4)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.