feat(library): Add customizable date format option for Library and History

[xARSENICx]

This commit introduces a user preference to customize how dates are displayed across the Mixxx library and history views. It addresses the request for ISO 8601 compliance and allows completely custom date strings.

Key Changes:

• Library Preferences UI:

  • Added a "Date Format" dropdown with standard presets (Native, ISO 8601, Regional Short/Long).
  • Added full Custom Format support: Users can type any valid Qt date format string (e.g., ddd dd/MM/yyyy) directly into the combobox.
  • Added a Live Preview label that updates instantly as the user types or selects a format.
  • Smart Persistence: Note that the logic remembers the user's last custom string even if they temporarily switch to a preset and back.

• Backend Integration:

  • BaseTrackTableModel now holds a static global date format string, ensuring all Library and History views update dynamically without a restart.
  • The format is saved persistently to mixxx.cfg under [Library], DateFormat.

• UI Layout Fixes:

  • Fixed an existing layout issue in the "Track Table View" preferences group where input fields (Library Font, BPM Precision) were not expanding to fill the available width.
  • Corrected the QGridLayout column stretch factors to ensure a consistent, full-width appearance for all preference rows.

Screen.Recording.2026-02-04.at.12.49.55.AM.mov

Fixes #15327

[xARSENICx]

I actually went ahead and made few changes (based on your suggestion majorly as an ensemble of all of them). Please go through the latest commit.
Some screenshots:

[ronso0]

Thanks for the quick implementation!
Though, neither a preset nor the custom format is persistent 🤔
I think that's because of the initial update in the ctor, the call of slotDateFormatChanged() which writes to config?

Besides that, it's not obvious that the format can be edited (not sure if that's what you referred to as bad UX?)
How about fixed presets and one "Custom" item? When the latter is selected the combobox is set editable ("Custom" text cleared, text cursor enabled). When it's confirmed, it's shown as let's say "yy+dd+MM (custom)" in the list.

Also, I'm struggling to understand the logic with the default, like what's the reasoning for
const QString BaseTrackTableModel::kDateFormatDefault = QString();?
(like, for the BPM display precision we pick the default kBpmColumnPrecisionDefault = 1 in the model so it doesn't rely on the UI/preferences)

If we go with a custom format, I suggest we add an enum class BaseTrackTableModel::DateFormat (the default is the current format) and use that for the combobox data role. (umm, looks like this requires to resolve the actual format string in both the preferences and track model with a helper function enum -> string?)
Then it would also be nice to show the options like this:

• Native (System Default)
• ISO 8601 (yyyy-MM-dd)
• Regional Short (d/M/yy)
• Regional Long (dd.MM.yyyy)
• Custom or: yy-MM+dd (Custom)

Admittedly, dealing with the Custom item makes the slotIndexChanged a bit complex and we also need a slotTextChanged.

---

TL;DR
I'll leave it to you to decide whether we merge a fixed preset implementatio first, or a full-blown version with custom format. Depends on your motivation, and obviously the effort (for the custom version, or potential later refctoring for the custom format).
Guess you already found a few more interesting features to work on, so if you go with the basic version I#m also fine to look into the custom version myself later on : )

[xARSENICx]

Thanks for this detailed discussion. I will look into it and take hints as to how to go ahead.
Even though there are other features I took up, I will ensure I finish implementing this too- not an issue. Need time till the weekend to do some good progress as I have some personal commitments.

[xARSENICx]

it's not obvious that the format can be edited (not sure if that's what you referred to as bad UX?)

Precisely yes!

a full-blown version with custom format.

Sounds good. Will implement it by the weekend, hopefully.

[xARSENICx]

Screen.Recording.2026-02-03.at.9.06.06.PM.mp4

How does this look to you? (needs polishing, for instance the font box above is also changing which is unintentional. will push commits once i take care of it, just wanna if this looks promising.)

[ronso0]

Yeah, looks good!
Would be cool (UX) if we could save the custom format so it's not erased when users try one of the presets.

[xARSENICx]

LMK if any more changes are required.

I updated the PR comment according to the latest commit.

Bumping for review @ronso0

[xARSENICx]

Did you get a chance to look at thi? @ronso0 (i feel u might have missed the notif)

[ronso0]

Did you get a chance to look at thi? @ronso0 (i feel u might have missed the notif)

Didn't miss it, just kept this in my TODO as other stuff had higher prio (bug fixes and my own stuff)
Will do a more thorough review soon, just left a comment for now.

In general I'd appreciate the clang format fixes (is it auto-run on the entire file for you?) being a separate commit. And the date feature can be squashed into one commit IMHO.
But that can be done just before merge when this gets approved.

[xARSENICx]

yeah, these clang format changes happen due to pre-commit. i will squash the commits as you said, before merge

[ronso0]

mostly LGTM, see my prposal about the enum

[ronso0]

since this is a Q_ENUM we don't need to cast to int and use
(at least this builds fine locally, let's see what the non-Ubuntu runners say)

Suggested change

	QVariant::fromValue(
	static_cast<int>(BaseTrackTableModel::DateFormat::Native)));
	QVariant::fromValue(BaseTrackTableModel::DateFormat::Native));

Likewise, in slotUpdate() we can use
int dateIndex = comboBox_dateFormat->findData(QVariant::fromValue(preset));

(there may be other occurences I overlooked)

[ronso0]

While this works fine we now have two date variants:

• selected preset/custom format in the tracks table
• localized date/time format in DlgTrackInfo

I wonder what the best way forward is to sync both.
-> no need to do this in this PR
DlgTrackInfo has a pointer to UserSettings so it could simply call mixxx::formatDate(date, format) and append the localized time string? We only need hours and minutes, and as far as I can tell it's always hh:mm and only the separators differ, with optional A/P suffix.
What do you think?

[xARSENICx]

I wonder what the best way forward is to sync both.

how about we go ahead and write a dedicated function in src/util/datetime.h?
Something like this?

/// Helper to format a QDateTime with a custom date format but using the system's
/// default locale for the time component.
/// This prevents the time from being dropped when the custom format is date-only.
inline QString formatDateTimeWithSystemTime(
        const QDateTime& dt,
        const QString& dateFormat = QString()) {
    if (!dt.isValid()) {
        return QString();
    }
    const QString dateStr = formatDate(dt.date(), dateFormat);
    const QString timeStr = QLocale().toString(dt.time(), QLocale::ShortFormat);
    return dateStr + QStringLiteral(" ") + timeStr;
}

Just food for thought, as IMO this will make future changes (like changing the separator to . from , if requested) easy to implement for any dev who hasn't worked on this previously, either.

I could open a new PR referencing this, once we get this merged. What say?

[xARSENICx]

I'd appreciate the clang format fixes (is it auto-run on the entire file for you?) being a separate commit

I tried to squash the commits like you explained with this approach:

soft reset
run pre commit on the file from `main` branch
make these clang format changes as a commit
go ahead and push the changes i made from stage

But, it was kinda hectic and still not completely perfect. Am I missing something?