[ML 0.1/UI.01.1] - Introduce Message List Item date time format customization

[rafaeltonholo]

Possible formats:

• Auto (default):

  • For messages from the same day: display the hour, according to the device's locale (e.g., 3:22 PM, 15:22).
  • For messages from "yesterday": display as Yesterday.
  • For messages from the same week (but not from "yesterday"): display the weekday name.
  • For messages from before the current week, but in the same year: display as Month day (e.g., Jan 2, Mar 24, Apr 1, Dec 25).
  • For messages from before the current year: display the date in Full mode, omitting the time.

• Full: Always display the full date and time, according to the device's locale (e.g., 9/15/2025, 3:22 PM, 15/9/2025, 3:22 PM, 9/15/2025, 15:22, 15/9/2025, 15:22).

Acceptance criteria:

• Create the MessageListDateTimeFormat preference option
• Add a new customization option under General Settings > Display > Message List
• Store the user's selection using the new PreferenceManager approach
• Default to Auto.

[alpharesearch]

@rafaeltonholo After implementing and testing the Auto and Full modes locally, I noticed one gap that might be valuable to address for power users.
​I suggest we add a third option: ISO 8601.
​Rationale:
While Full is great because it respects the Android system locale, technical users often prefer a deterministic, unambiguous format (YYYY-MM-DD HH:mm) that doesn't change based on the device language.
​Full (Locale US): 1/17/2026 12:45 PM
​Full (Locale DE): 17.01.2026 12:45
​ISO 8601: 2026-01-17 12:45 (Always the same)
​Since the architecture (Enum/ListPreference) is already being put in place, adding ISO to the MessageListDateTimeFormat enum would be a low-effort addition that aligns well with Thunderbird's technical user base.

[alpharesearch]

Hi @dani-zilla,

I recently started looking into this feature and you were already assigned—sorry for the overlap!

As a test I have implemented and tested an ISO 8601 option (e.g., 2026-01-17 14:30), which is often requested by power users who prefer a deterministic, unambiguous format over the system locale defaults.

If you think this would be a good addition, I pushed that specific implementation to a clean commit here. Please feel free to cherry-pick it or reference it for your implementation:

alpharesearch@69509a3

Thanks for working on this!