Confirmed :)

After changing that single line, the time/date display switches 
correctly with the first poll after midnight.

Regards,
Jens

thank you for your suggestion - I have updated the file and will 
report back the results!

Regards,
Jens

An issue might be that you are running 6.1 and I am running 6.2.

Comparing the two, I wonder if this is causing problems (i.e. make 
this change on your file):

diff --git a/imp/lib/Ajax/Application/ListMessages.php 
b/imp/lib/Ajax/Application/ListMessages.php
index 00cd4aa..a084baa 100644
--- a/imp/lib/Ajax/Application/ListMessages.php
+++ b/imp/lib/Ajax/Application/ListMessages.php
@@ -141,7 +141,7 @@ class IMP_Ajax_Application_ListMessages
              $parsed = $imp_imap->parseCacheId($args['cacheid']);
              $uid_expire = true;

-            if (!$parsed['date'] != date('z')) {
+            if ($parsed['date'] == date('z')) {
                  try {
                      $imp_imap->sync($mbox, $parsed['token'], array(
                          'criteria' => Horde_Imap_Client::SYNC_UIDVALIDITY

The key to this might be the following observation:

The data element of the viewport object is empty, in the first poll 
response after midnight.

A future poll, which reports a new message, does have the viewport 
object, but with a data element containing the new entry's field values:

{"response":true,"tasks":{"imp:viewport":{"label":"Posteingang","totalrows":39,"rowlist_reset":true,"rowlist":{"39002":1,"39001":2,"38989":3,"38965":4,"38963":5,"38904":6,"38903":7,"38785":8,"38722":9,"38632":10,"38571":11,"38569":12,"38560":13,"38535":14,"38297":15,"38187":16,"37993":17,"37893":18,"37878":19,"37871":20,"37826":21,"37684":22,"37412":23,"37137":24,"35362":25,"35255":26,"35109":27,"34242":28,"33979":29,"33926":30,"31722":31,"30608":32,"28412":33,"23231":34,"18485":35,"11078":36,"38537":37,"9889":38,"6262":39},"data":{"39002":{"flag":["personal","unseen"],"size":"5 KB","date":"00:13:48","from":"noreply@bugs.horde.org","subject":"[Tickets #9773] Re: Date column not updated after midnight"}},"cacheid":"VTM5MDAzLFYxMjU2NTc2OTUwLEgzMjY5Nw==|1|1|D43","view":"SU5CT1g"},"imp:poll":{"SU5CT1g":1,"SU5CT1gvQWJsYWdlL21haWxpbmctbGlzdHM":3,"SU5CT1gvQWJsYWdlL05ERSBBRy9LdW5kZW4vT0ZEIE5pZWRlcnNhY2hzZW4vTlotUHJvYmxlbWU":0,"SU5CT1gvQWJsYWdlL1ByaXZhdC9GaW5hbnplbi9EZXV0c2NoZSBCYW5r":0,"SU5CT1gvanVuaw":0,"dXNlci9hbW96ZHplbg":1},"imp:quota":{"m":"Keine 
Begrenzung","p":0,"l":""}}}

I tend to assume that the browser's message list is not replaced (with 
a version with updated time stamps) because no new entries' data was 
sent with that "after midnight" poll response.

Here's the JSON from the first poll after mid-night. I see no other 
requests but the imp/poll and imp/toolbarUpdate at regular intervals 
(unless, of course, I'd manually interact with IMP - which I didn't do 
during this test).

{"response":true,"tasks":{"imp:viewport":{"label":"Posteingang","totalrows":38,"rowlist_reset":true,"rowlist":{"39001":1,"38989":2,"38965":3,"38963":4,"38904":5,"38903":6,"38785":7,"38722":8,"38632":9,"38571":10,"38569":11,"38560":12,"38535":13,"38297":14,"38187":15,"37993":16,"37893":17,"37878":18,"37871":19,"37826":20,"37684":21,"37412":22,"37137":23,"35362":24,"35255":25,"35109":26,"34242":27,"33979":28,"33926":29,"31722":30,"30608":31,"28412":32,"23231":33,"18485":34,"11078":35,"38537":36,"9889":37,"6262":38},"data":[],"cacheid":"VTM5MDAyLFYxMjU2NTc2OTUwLEgzMjY5Ng==|1|1|D43","view":"SU5CT1g"},"imp:poll":{"SU5CT1g":0,"SU5CT1gvQWJsYWdlL21haWxpbmctbGlzdHM":3,"SU5CT1gvQWJsYWdlL05ERSBBRy9LdW5kZW4vT0ZEIE5pZWRlcnNhY2hzZW4vTlotUHJvYmxlbWU":0,"SU5CT1gvQWJsYWdlL1ByaXZhdC9GaW5hbnplbi9EZXV0c2NoZSBCYW5r":0,"SU5CT1gvanVuaw":0,"dXNlci9hbW96ZHplbg":1},"imp:quota":{"m":"Keine 
Begrenzung","p":0,"l":""}}}

Further imp/poll again have only the "short version" answer:

{"response":true,"tasks":{"imp:poll":{"SU5CT1g":0,"SU5CT1gvQWJsYWdlL21haWxpbmctbGlzdHM":3,"SU5CT1gvQWJsYWdlL05ERSBBRy9LdW5kZW4vT0ZEIE5pZWRlcnNhY2hzZW4vTlotUHJvYmxlbWU":0,"SU5CT1gvQWJsYWdlL1ByaXZhdC9GaW5hbnplbi9EZXV0c2NoZSBCYW5r":0,"SU5CT1gvanVuaw":0,"dXNlci9hbW96ZHplbg":1},"imp:quota":{"m":"Keine 
Begrenzung","p":0,"l":""}}}

Finally I got around to testing this with Firebug - I'm sorry for the delay.

After a fresh page reload (I had logged in previously, selected my 
INBOX for display and selected your latest Horde bug reply - then I 
hit the browser's "reload" icon), I do see the mentioned imp:viewport 
with it's cache id as part of the imp/dynamicInit POST request:

cacheid         "VTM5MDAyLFYxMjU2NTc2OTUwLEgzMjY5Ng==|1|1|D42"

From then on, imp/poll POST requests (besides the toolbar updates) 
are the only requests I see, either automatically or by pressing IMP's 
"update" link. Their response JSON only has imp:poll and imp:quota 
objects in "tasks" - neither contain a cacheid.

The first imp/poll after midnight then actually has a viewport object 
with a cacheid element:

cacheid        "VTM5MDAyLFYxMjU2NTc2OTUwLEgzMjY5Ng==|1|1|D43"

This is indeed different from the cacheid reported initially, but as 
observed previously, the time stamps in the message list remain as 
"time-only" even after the imp/poll requests after midnight.

Further requests again have no viewport object in their responses.

Seems like the cache id change goes by unnoticed?

Regards,
Jens
The currently installed version is imp 6.1.6 from PEAR.

Firebug is probably best.  The cacheid is sent in the imp:viewport 
task object contained in the JSON responses to various mailbox actions.

It looks something like this: "VTIxMTkyLFYxMjU1Njg1MzM4LEg1MDEwNQ==|9|0|D34"

attached a "proof-of-notworking4me" image from today - you can clearly 
see yesterday's messages with time-only timestamps. It's from a 
session run over-night.

According to "pear list-ugrades", the server is running the latest 
modules as of today. I had run a "horde-clear-cache" after the recent 
upgrade (which, iirc, included an update to some caching module). But 
these symptoms have been here since forever, not just after the recent 
upgrade. And in case it might matter, we're running Kolab backends here.

How may I trace this "browser cache ID" thing - I ran a network trace 
last night, but unfortunately forgot to tune down the encryption 
methods... wireshark wouldn't decode the SSL traffic despite having 
the private server key :[ Is that the right traffic to look at (so I'd 
repeat the test next night) or is this something that acts either 
client-side only or server-side only?

This still is low prio to me, but since I've already started looking 
into this, I offer to take it further...

Verified working.  The browser cache ID for a mailbox is appended with 
a string of the form "D###" where ### indicates the current day of the 
year.  This cache id is guaranteed to change after midnight, at which 
point the browser empties its message cache and fetches a new mailbox 
slice from the server (with the updated dates).

doesn't work for me (see #12940) with IMP 6.1.6, Horde_Imap_Client 
2.17.1. IMAP server is Cyrus 2.4.17.

Do I read it correctly, that I should trace the first IMAP call after 
a (server) date change to see what is going wrong?

Changes have been made in Git for this ticket:

Fix regressions in search mailboxes due to Ticket #9773
Move UIDVALIDITY check before empty mailbox check, since a UIDVALIDITY
failure should cause all viewport information to be reset, regardless of
whether the mailbox contains messages.

UIDVALIDITY will also fail when the day changes, so metadata creation
needs to appear below this line since metadata will be reset in this
instance.

  2 files changed, 36 insertions(+), 36 deletions(-)
http://git.horde.org/horde-git/-/commit/6f435e07cd2a1419a35c1de8f73fa81cc3d22b9c

Changes have been made in Git for this ticket:

[mms] Purge browser cache daily in dynamic view; updates time stamps 
to proper format (Request #9773).

  6 files changed, 54 insertions(+), 25 deletions(-)
http://git.horde.org/horde-git/-/commit/b56b7893d8fbba53ea6498709809edb65a06f0ba

This is really just a cosmetical issue. But after midnight, 
yesterday's messages are not updated to only show the date. This would 
actually be fine, but if you navigate to a mailbox after midnight that 
hat receiced new messages before midnight, you now have mixed date and 
time for yesterday's messages.