Pidgin incorrectly inserts date into conversation spanning midnight

[varchar255]

When a conversation spans midnight, Pidgin displays the date in the timestamp in the conversation window but not in the message logs. I'm using the Message Timestamp Formats plugin with the following options:

---
Force 24-hour time format: checked

Show dates in...
Conversations: For delayed messages
Message Logs: For delayed messages
---

Since Pidgin is displaying the dates in the conversation window only but the preferences are the same, either the conversation window should not display the date, or the message log should. The date is displayed when a conversation spans midnight regardless of how much time has passed since the last message. I was using Gaim 2.0 beta 6 previously and it never displayed the date after spanning midnight, so I think the conversation window behavior is currently incorrect.

Steps to Reproduce:
Open a new conversation window and start talking. Send a message close to midnight (i.e. 11:58 pm). Keep the window open. The first message that arrives after midnight will have the date included.

Observed behavior:
Pidgin adds the date to the conversation window when the conversation spans midnight.

Expected behavior:
Pidgin should not add the date just because the conversation spans midnight.

This happens on Pidgin 2.1.0, Windows XP.

[datallah]

I think this is working as intended, it will always show the date on the first message in a new day, or if the message is older than 20 minutes. It will additionally show the date under the conditions in the timestamp format plugin.

The only thing I'm unsure about is why the logging timestamp works slightly differently and doesn't add the date when the conversation spans midnight.

This behavior could be overridden by different plugin.

[rlaager]

I seem to remember seeing the logging was broken. I should fix that soon.

[bernmeister]

Is this still busted in Pidgin 2.5.8? If so, perhaps this ticket should be moved to Patches Welcome.

[bernmeister]

Could this be a duplicate of #360?

[deryni]

This has nothing to do with #360.

[varchar255]

I haven't had a chance to see whether the bug still exists in 2.5.8, but I've gotten used to the current behavior so I don't particularly care anymore.