Bug 457479

What locale are they using? Here with German locale I don't have to enter any spaces. The date input depends on your locale, my input is also dd.mm.yyyy.

Maik

(In reply to Maik Qualmann from comment #1)
> What locale are they using? Here with German locale I don't have to enter
> any spaces. The date input depends on your locale, my input is also
> dd.mm.yyyy.
> 
> Maik

Default: HU (but now I tryed EN and need the space)

(In reply to Peter from comment #2)
> (In reply to Maik Qualmann from comment #1)
> > What locale are they using? Here with German locale I don't have to enter
> > any spaces. The date input depends on your locale, my input is also
> > dd.mm.yyyy.
> > 
> > Maik
> 
> Default: HU (but now I tryed EN and need the space)

Here is a short video about the problem: https://mega.nz/folder/kFwQ3bjQ#WwX3g0u6OlKwOD9Zef_fEA

Well if I set my system to Hungarian I can reproduce it. Changing the language in digiKam does not affect the date or number format. At the request of users and bug reports, the date format should be retained by the system, only the language should change in digiKam. I actually didn't think that was correct.
The question now is, is the date format in Hungarian so common with spaces and a period at the end, or did Qt make a mistake here? I could only find out in web that yyyy.mm.dd is used in Hungary.

Maik

(In reply to Maik Qualmann from comment #4)
> Well if I set my system to Hungarian I can reproduce it. Changing the
> language in digiKam does not affect the date or number format. At the
> request of users and bug reports, the date format should be retained by the
> system, only the language should change in digiKam. I actually didn't think
> that was correct.
> The question now is, is the date format in Hungarian so common with spaces
> and a period at the end, or did Qt make a mistake here? I could only find
> out in web that yyyy.mm.dd is used in Hungary.
> 
> Maik

Unfortunately this format grammatically is correct (with spaces): yyyy. mm. dd.
But entering the date in this format is slow and may result in errors (digiKam does not change the date to the new date, but restores the old -- original and and possibly faulty -- date).
I saw several users how enter a date on the date field, and they always wrote it that way: yyyy.mm.dd. (without spaces). DigiKam didn't accept it and they didn't know what happened. I think in this case it is not a mistake if DigiKam does not adhere to the spelling rules. The date is also valid and usable in this case, and and data entry will be faster... ...or digikam needs to format the date after data entry.
What do you think?

Oracle also changed the Hungarian date format to with spaces:

https://community.oracle.com/tech/developers/discussion/4074048/hungarian-date-format-changed

Maik

We can remove the spaces, but if the user then types it correctly with spaces, it would probably result in an error. We cannot support both formats in one QDateTimeEdit.

Alternatively, you could set an environment variable in an appropriate language to get the desired date input format before starting digiKam.

Maik

(In reply to Maik Qualmann from comment #6)
> Oracle also changed the Hungarian date format to with spaces:
> 
> https://community.oracle.com/tech/developers/discussion/4074048/hungarian-
> date-format-changed
> 
> Maik

Maybe because it is grammatically correct...
But this format makes bulk data entry extremely slow, and increases the number of errors (user add wrong date to the images, because the because the date is reset to the original value).

> Alternatively, you could set an environment variable in an appropriate
> language to get the desired date input format before starting digiKam.
> 
> Maik

I changed the system regional settings: Short date: yyyy.mm.dd.
In this case the digiKam is works well. Thanks for the idea!