Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MU4 Issue] The date macros ($d, $D, $M) for header/footer show the dates in US format (MM/DD/YY) #15437

Open
Jojo-Schmitz opened this issue Dec 20, 2022 · 25 comments
Assignees
Labels
P2 Priority: Medium

Comments

@Jojo-Schmitz
Copy link
Contributor

Jojo-Schmitz commented Dec 20, 2022

Describe the bug
The date macros ($d, $D, $M) for header/footer show the dates in US format (MM/DD/YY)

Expected behavior
Same as MuseScore 3 and before: obey MuseScore's language settings or the computer's regional settings

As an alternative (and the least thing to do) use the ISO format, YYYY-MM-DD

@Jojo-Schmitz Jojo-Schmitz changed the title [MU4 Issue] The date (and time) marcos for header/footer show the date in US format (MM/DD/YY) [MU4 Issue] The date macros ($d, $D, $M) for header/footer show the dates in US format (MM/DD/YY) Dec 20, 2022
@krtschil
Copy link

Tried with

  • MU4 - Official: Language setting is German. Date format is also German
  • Nightly: Language setting is English. Date format is German

OS: Linux

@Jojo-Schmitz
Copy link
Contributor Author

Jojo-Schmitz commented Dec 20, 2022

Not so on my Windows 11. System, Language and Date settings all in German, MuseScore date shows in US format

And it isn't just me but also the user from https://musescore.org/de/node/339004

@wolf404
Copy link

wolf404 commented Dec 27, 2022

Confirmed on Windows 10 21H2 (19044.2251): even after explicitly setting MS4 to German the dates are still in US format.
Tested with official (MuseScore version (64-bit): 4.0.0-223472200, revision: github-musescore-musescore-5485621) and 27 Dec nightly (MuseScore version (64-bit): 4.0.0-223610304, revision: github-musescore-musescore-002fd32)

@krtschil
Copy link

Confirmed on Windows 10 too. Date is always in US format

@wolf404
Copy link

wolf404 commented Dec 27, 2022

I see the code differences, but my cpp skills are too limited to draw the right conclusions from what I see...

version 4:

d += Date::currentDate().toString(DateFormat::LocaleShortFormat);

version 3.6.2:

d += QDate::currentDate().toString(Qt::DefaultLocaleShortDate);

@Jojo-Schmitz
Copy link
Contributor Author

So an issue in MuseScore's own string lib?

@wolf404
Copy link

wolf404 commented Jan 8, 2023

As said: I don't have a clue of cpp so I cannot judge....
But it might well be that the Date object always and only uses the underlying C locale (en_US). As long as you are on an en_US system it does not matter for obvious reasons, but there must have been a reason to use QDate and Qt localization previously.

@cbjeukendrup
Copy link
Contributor

A bit of background: the reason that we are not using Qt anymore for this, is that we don't want our engraving library to depend on such a specific and huge framework as Qt, which is primarily used for building user interfaces. To mention one advantage: without this huge dependency, it becomes much easier to use our library in other applications, if anyone would ever want that. Another is that our engraving module is safe when a new major version of Qt is released, or if Qt suddenly quits its open source licenses, like they are already doing for LTS releases.
However, the "loss" of Qt inevitably has some disadvantages; in some places, its easy localisation system will be missed. The solution might be to write a wrapper for Qt, like we have done for QPainter; so in this case, we could create an interface like "ILocalizationProvider" which would be used for various localised formatting tasks, with an underlying Qt implementation, but this implementation is hidden from the rest of the engraving module.

@wolf404
Copy link

wolf404 commented Jan 8, 2023

For me it would be sufficient to have a possibility to specify my preferred date & time format somewhere (e.g. close to the language setting in general preferences).
Actually that would be even better than localization because I could use universal ISO format...

@Jojo-Schmitz
Copy link
Contributor Author

Jojo-Schmitz commented Jan 8, 2023

If not configurable or as per locale, ISO format is the only right and sensible choice (and US format being the worst and wrongest choice). Also that, and only that, should be in used on musescore.com, i.e. by the backend.

@mattok
Copy link

mattok commented Jan 12, 2023

After uprgading my scores to version 4, I'm being bitten by this bug too, with the wrong date being displayed (for my locale - day and month in wrong order). I would ideally like to see:

  1. The application picks up the locale of the local OS, whatever that is. (I appreciate that this is probably the hard part, given that MuseScore works cross-platform - which is important - and so probably has to account for all possible local OS libraries for determing it. I'm imagining lots of ifdefs.)
  2. By default, new scores pick up the locale of the application, and the locale gets stored into the new score file, affecting how it is formatted. (This way, if the file is sent to someone else, it displays exactly as it was authored. That's my preference for the default anyway, since it is least likely to catch someone out, but an alternative for the default could be for it to always pick up what the application locale is.)
  3. The musescore file locale can be altered by the user. (A specific locale can be chosen, or it can be set to always pick up the application locale.)
  4. The date format can be configured. My preference would be for placeholders representing the "conversion specifiers" of strftime's format string to be added to the existing ones already available for use within the header and footer text input fields. Y, y, m and d at a minimum.

Of these, number 4 is the most important. With number 4, it is possible to write a date in a locale-independent way (e.g. Y-m-d), which would make it possible to work around the problem of determining the user's locale problem, which sounds like more of a challenge. It would hopefully be a simple partial fix.

@Jojo-Schmitz
Copy link
Contributor Author

Jojo-Schmitz commented Jan 13, 2023

The choice of the US format is the worst of all...
For me this issue is a showstopper (not the only one though) for updating my scores to 4.0, as I'm using Version $Mon all my scores, and that US format is just confusing as hell to non-US users

@wolf404
Copy link

wolf404 commented Jan 16, 2023

@cbjeukendrup : any chance to quickly change the default format to ISO (yyyy-MM-dd) instead of LocaleShortFormat?

d += Date::currentDate().toString(DateFormat::LocaleShortFormat);

That would for sure be an excellent workaround for all non-US users - a really quick win with minimal effort.

@Jojo-Schmitz
Copy link
Contributor Author

Yes, ISO would be the very least thing to do here. At least for a 4.0.2.
For 4.1 I'd rather see a more adcanced solution

@cbjeukendrup
Copy link
Contributor

Let's try that. See #15906.

@Tantacrul This seems indeed appropriate for 4.0.2 (and is low risk anyway)

@Tantacrul Tantacrul added this to To do in [MU4.0.2 PATCH-RELEASE] via automation Jan 16, 2023
@Tantacrul Tantacrul added P2 Priority: Medium P3 Priority: Low and removed P2 Priority: Medium labels Jan 16, 2023
@cbjeukendrup cbjeukendrup moved this from To do to In progress in [MU4.0.2 PATCH-RELEASE] Jan 16, 2023
cbjeukendrup added a commit that referenced this issue Jan 16, 2023
Temp fix #15437: Use ISO date format instead of locale which doesn't work
[MU4.0.2 PATCH-RELEASE] automation moved this from In progress to Done Jan 16, 2023
@cbjeukendrup
Copy link
Contributor

Reopening awaiting a proper solution for 4.1

@cbjeukendrup cbjeukendrup reopened this Jan 16, 2023
@cbjeukendrup cbjeukendrup moved this from Done to Needs porting in [MU4.0.2 PATCH-RELEASE] Jan 16, 2023
@cbjeukendrup cbjeukendrup added this to To do in 4.x SHORTLIST via automation Jan 16, 2023
@Jojo-Schmitz
Copy link
Contributor Author

Came up again in https://musescore.org/en/node/342785

@RomanPudashkin RomanPudashkin moved this from Needs Porting to Needs Triage in [MU4.0.2 PATCH-RELEASE] Jan 19, 2023
@Tantacrul Tantacrul removed this from Needs Triage in [MU4.0.2 PATCH-RELEASE] Jan 30, 2023
@Tantacrul Tantacrul added this to To triage in MuseScore 4.1 via automation Jan 30, 2023
@Tantacrul Tantacrul removed this from To do in 4.x SHORTLIST Jan 30, 2023
octopols pushed a commit to octopols/MuseScore that referenced this issue Jan 31, 2023
@Jojo-Schmitz
Copy link
Contributor Author

Jojo-Schmitz commented Mar 14, 2023

Hasn't this fix made it into 4.0.2?
If so it doesn't work, I still see MM/DD/YY rather than YYYY-MM-DD

@Tantacrul
Copy link
Contributor

Reopening awaiting a proper solution for 4.1

Based on @cbjeukendrup's comment, I'd say 'no'.

@Jojo-Schmitz
Copy link
Contributor Author

That comment shouldn't indicate that, just that for 4.1 a more complete solution is wanted than the simple ISO date one for 4.0.2.
But instead the ISO version went into master but not into 4.0.2 :-(

@Tantacrul
Copy link
Contributor

I must admit, this one was handled by other folk, so I think I'll wait for someone who was involved to comment. Apologies, just a little busy so can't quite take time to look.

@cbjeukendrup
Copy link
Contributor

@Tantacrul The plan was to put a low-risk trivial fix in 4.0.2, and work on a more complicated fix for 4.1. According to the history of this thread, I communicated this back then, and you added it to the 4.0.2 project accordingly.

But then there was a misunderstanding/whatever: the fix for 4.0.2 had been merged to master, and you moved the issue to the 4.1 project, awaiting the promised proper fix, but at that point the fix intended for 4.0.2 had not yet been cherry-picked to the 4.0.2 branch. And because the issue had been removed from the 4.0.2 project, that never happened anymore, unfortunately.

Let's hope that the months until 4.1 will pass quickly :)

@Tantacrul
Copy link
Contributor

Ah, well sorry if this seems rather convoluted. It is entirely likely that someone on the dev team asked me to move it for some reason. At least if it is assigned to 4.1, we still have the task prepared to be worked on.

@bkunda bkunda added this to To do in 4.x SHORTLIST via automation May 8, 2023
@Jojo-Schmitz
Copy link
Contributor Author

Anything happening on this?

@grigorax
Copy link

I too am annoyed by the US format even though it has a logic of its own ... Thanks for the background info, I now appreciate more the convolutions that go with this seemingly small issue.

@cbjeukendrup cbjeukendrup added P2 Priority: Medium and removed P3 Priority: Low labels Jun 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 Priority: Medium
Projects
Status: One of the next releases
4.x SHORTLIST
  
To do
MuseScore 4.1
  
To triage
Development

No branches or pull requests

7 participants