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?

[ronso0]

The utility proposal sounds good!

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

You don't need to run precommit manually ( in case you did), most hooks are supposed to run on git commit and git push.
Changes LGTM, thank you!

[ronso0]

Oh wait, a .DS_store file slipped in, please remove.
And I overlooked a ui change

[ronso0]

why do we need this now?

[xARSENICx]

when i was working on this feature, without this line, empty, unused gray space was present to the right of the other controls, instead of the controls expanding to fill the dialog width as expected. so i thought of having a belt and suspenders precaution at that moment. seems like this slipped to prod too.

removing it does absolutely nothing as .ui file does seem to be handling this well, thanks for pointing it out. i will go ahead and squash the change.

[ronso0]

ah okay. I think we can also put the format selector and the preview into a QHBoxLayout. will take a look later on

[xARSENICx]

I think we can also put the format selector and the preview into a QHBoxLayout.

That is the exact implementation that I went with, already.

[ronso0]

ah okay, didn't check.
then maybe we can adjust the sizepolicies so that the combobox has minimum width¹ and the preview can expand to move it to the left?

¹Minimum for the box and MinimumExpand for the label should work as the fixed date items are likely wider than any reasonable custom date string

[xARSENICx]

reasonable

:), well that is indeed true. but, i believe leaving it in the current form is also decent UX. up for discussion, as ur suggestion is totally reasonable.

[xARSENICx]

You don't need to run precommit manually

Yeah, I am aware of that. I was asking about cleaning up the commits. Initial commits were not clean as clang-formatting got coupled with code changes. So, i wanted to understand the contribution flow for such situations.

The utility proposal sounds good!

I will go ahead and open a PR, once this gets merged, to address that then. You can then review the final code changes there.

[ronso0]

Loks good except one issue:
after first start (no config value -> use Native) the preview label is not updated.

This fixes it for me
9bab5c7
If you go along with this, please cherry-pick, sqash and force-push -- then we finally merge this 👍

[xARSENICx]

the preview label is not updated.

Thanks for testing the feature so well <3.
I went ahead and pushed your fix-up. Had fun working on this UI change.

[ronso0]

Nice, let's go.
Thanks for this feature!

[ronso0]

Oh oh, looks like we broke something with the last fixup:

• format is not applied
• date filter in Analyze is broken

I'll prepare a fixup..

[ronso0]

#16047

@xARSENICx can you take a look?

[xARSENICx]

Am so sorry @ronso0 , I informed in Zulip that I won't be able to contribute during this week. Is there any way this could wait till the 2nd of March?
I could take a look at the fixup meanwhile but I don't have access to my laptop, so I am not sure how much help I can offer- but let me try.

[xARSENICx]

The changes look fine to me; I was unaware of the breakage. If the fixup works for you then please feel free to merge- I have no means to test it immediately. I will try to get back to this ASAP though- but if it fixes things for now, then we should move forward with it.

[ronso0]

I informed in Zulip that I won't be able to contribute during this week

Oh sorry, forgot about that. Good luck with your exams!
I'm sure a core dev can review this soon.