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.

Sign up for GitHub

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

Jump to bottom

Calendar reports invalid date format when using ca_ES locale #24533

Closed
sethhillbrand opened this issue May 15, 2024 · 4 comments
Closed

Calendar reports invalid date format when using ca_ES locale #24533

sethhillbrand opened this issue May 15, 2024 · 4 comments
Assignees
@vadz

Comments

@sethhillbrand
Copy link

sethhillbrand commented May 15, 2024 •
edited by vadz

Description

Bug description:

Wx does not appear to recognize dates for Linux systems when running in Catalan locale (ca_ES.UTF-8)

Expected vs observed behaviour:

Selecting a calendar date in the wx calendar sample fails verification. Note that this is not only when typing the date in but also when selecting the calendar date using the widget.

image

To Reproduce:

Steps to reproduce the behaviour, please make them as detailed as possible.
For example:

  1. Set system locale to ca_ES.UTF8
  2. Run wxWidgets Calendar sample application
  3. Choose a date from the calendar
  4. See error

Platform and version information

  • wxWidgets version you use: 3.2.4
  • wxWidgets port you use: wxGTK
  • OS and its version: Fedora 40. Also Ubuntu 22.04
    • GTK version: 3.24
    • Which GDK backend is used: X11
    • Desktop environment : Gnome (also observed with Cinnamon)

See also https://gitlab.com/kicad/code/kicad/-/issues/17992 . Apparently affects Czech language as well but not French
@vadz vadz self-assigned this May 15, 2024
@vadz
Copy link
Contributor

vadz commented May 15, 2024

Thanks, I see it with both 3.2 and master, will debug/fix a.s.a.p.

@vadz
Copy link
Contributor

vadz commented May 15, 2024

OK, I have a fix but I think I need to improve/generalize it before making the PR.

The problem is that cs_ES, as well as cs_CZ and a bunch of Indian and Nepal locales use %-d and/or %-m in their d_fmt, i.e. a non-standard (documented as a glibc extension in BSD (!) strftime(1) and I couldn't find it documented in Open Group specifications) format specifier not recognized by wxDateTime. It's easy enough to add support for it (and I did it), but there are other specifiers we still don't support, at least %Od, %Om and %Oy used in Iranian and Burmese locales. It's probably worth adding support for those as well, but even we do this, the problem might still arise in the future with some new/unknown specifiers, so I'd like to change the generic wxDatePickerCtrl to always allow the user to enter the date in ISO 8601 format as a fallback to ensure that even the users of rare locales can use it.

Please let me know if anybody has any comments about this.

@sethhillbrand
Copy link
Author

That sounds like a good plan. Thanks!

vadz added a commit to vadz/wxWidgets that referenced this issue May 17, 2024
@vadz
Use ISO 8601 in wxDatePickerCtrl if current locale can't be used
8e66698 
Some locales use format specifiers not supported (yet) by
wxDateTime::Parse() and while the best fix is to add support for them,
as it has been already done for %F (see wxWidgets#24173) and will be done for
"%-" (see wxWidgets#24533) soon, it still seems wise to handle the locales for
which it still might happen, now or in the future, more gracefully by
falling back to ISO 8601 date format if the locale format can't be used
because we can't parse it.

Note that an alternative approach could consist in using the locale
format for formatting the dates and falling back to ISO 8601 only for
parsing them, but it would arguably be confusing to the user if the
program expected input in a format different from what it uses for
displaying the dates, so prefer just using the same format for both, if
we can't do otherwise.
@vadz vadz mentioned this issue May 17, 2024
Merged
@vadz
Copy link
Contributor

vadz commented May 17, 2024

The PR above fixes parsing dates in ca_ES and cz_CZ and adds fallback to ISO 8601 if the locale date format can't be used, as proposed, but doesn't implement support for %E* and %O* as this is much more involved: for the former, we need to use the alternative day/month forms (which, I think, correspond to the wxDateTime::NameForm values, but I haven't actually tested this) and for the latter we need to use the alternative digits (e.g. U+06F0 instead of 0 etc).

So parsing dates in the following locales, available on my Debian system, still doesn't work correctly:

  • az_IR
  • fa_IR
  • lo_LA
  • lzh_TW
  • mnw_MM
  • my_MM
  • or_IN
  • shn_MM
  • th_TH

But with ISO 8601 it's a bit less catastrophic as before.

@vadz vadz closed this as completed in 2cc3a38 May 19, 2024
vadz added a commit to vadz/wxWidgets that referenced this issue May 19, 2024
@vadz
Use ISO 8601 in wxDatePickerCtrl if current locale can't be used
670280f 
Some locales use format specifiers not supported (yet) by
wxDateTime::Parse() and while the best fix is to add support for them,
as it has been already done for %F (see wxWidgets#24173) and will be done for
"%-" (see wxWidgets#24533) soon, it still seems wise to handle the locales for
which it still might happen, now or in the future, more gracefully by
falling back to ISO 8601 date format if the locale format can't be used
because we can't parse it.

Note that an alternative approach could consist in using the locale
format for formatting the dates and falling back to ISO 8601 only for
parsing them, but it would arguably be confusing to the user if the
program expected input in a format different from what it uses for
displaying the dates, so prefer just using the same format for both, if
we can't do otherwise.

(cherry picked from commit 8e66698)
vadz added a commit to vadz/wxWidgets that referenced this issue May 19, 2024
@vadz
Support padding format flags in wxDateTime::ParseFormat()
23f976c 
This is not really used when parsing, but we still need to support the
GNU extensions to the strftime() formatting specifiers used to change
padding, as they can (and do, at least in the case of "%-d" and "%-m")
occur in the locale descriptions and so can be used when parsing dates
using the current locale format.

See wxWidgets#24533.

(cherry picked from commit 2cc3a38)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@vadz vadz

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@vadz @sethhillbrand