Hi,

I am not able to reproduce this issue.

Could you send me a screen capture before and after?
What is you language?

Ragards,
Stephane

Here you go:

http://webmshare.com/aRXOj

Hi,

This is not a bug. I will explain why:
1- You select with the popup the date 30 July 2015
2- Due to your settings, the date is written 7/30/15
3- Skrooge uses this string to interpret the date
4- Because the year of the date is partial, the string is interpreted as 30 July 1915

This is not a bug because there is no solution to know how to understand a partial date like 7/30/15.

To fix this issue and avoid misunderstanding, you should change your system settings (KDE) to write date with full year like this 7/30/2015.

I will close this incident.

Confirm, I have this bug too. Skrooge 2.0.91BETA, KDE Frameworks 5.12.0, Mageia Cauldron x86_64.

Why you closed it? This is definitely a bug. I have standard settings for my locale and Skrooge should work with that. I should not change anything in system settings for some application. This even can break some some things in a different places. I don't even see, where I can change that date format.

Skrooge 1 with KDE4 works fine and has no this problem. So this is a regression.

May be this is a bug not in Skrooge, but in some KDE component. So please, reopen this bug and fix it or reassign to corresponding component maintainer. Thanks.

I will explain why this is not a bug.
The date widget is a free text widget.
So, if the user enters this "7/30/15", how skrooge should interpret this?
30 Jul. 2015 ? Or 30 Jul. 1915 ?

i don't know and you don't know too.
There is no way to understand the aim of the user.

I do not enter text in the widget. I use calendar, select date here and it is displayed in this widget like 03.08.15. In calendear the date also displayed as dd.mm.yy. May be this is a bug in calendar?

I also found that in Skrooge 1 the date is in form dd.mm.yyyy.

Created attachment 93875 [details]
Calendar widget in Skrooge; locale ru_ua

The calendar is just a helper to fill the text field.
The text field can be fill with "7/30/15" by 3 different ways:
1- Because the user enters "7/30/15"
2- Because the user selects "30 Jul 2015" or "30 Jul 1915" or "30 Jul 1815" and because the KDE setting for date is defined with partial year.
3- Because the user selects and operation with date "30 Jul 2015" or "30 Jul 1915" or "30 Jul 1815" and because the KDE setting for date is defined with partial year.

At the end, the text "7/30/15" is interpreted has "30 Jul 1915" by Qt API.

I don't know what I can do.
You should have the same issue with all application managing dates.

My advice is to use format with complete year (7/30/2015) to avoid bad interpretation.

Created attachment 93877 [details]
attachment-25220-0.html

Well, bug or not, this is some wonky behaviour:
http://webmshare.com/done/8Lj5V

Notice that I didn't even enter a date, I selected it from the calendar and
the it changed on its own when activating another field.

On Mon, Aug 3, 2015 at 5:35 PM, Stephane MANKOWSKI <stephane@mankowski.fr>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=350722
>
> --- Comment #8 from Stephane MANKOWSKI <stephane@mankowski.fr> ---
> The calendar is just a helper to fill the text field.
> The text field can be fill with "7/30/15" by 3 different ways:
> 1- Because the user enters "7/30/15"
> 2- Because the user selects "30 Jul 2015" or "30 Jul 1915" or "30 Jul
> 1815" and
> because the KDE setting for date is defined with partial year.
> 3- Because the user selects and operation with date "30 Jul 2015" or "30
> Jul
> 1915" or "30 Jul 1815" and because the KDE setting for date is defined with
> partial year.
>
> At the end, the text "7/30/15" is interpreted has "30 Jul 1915" by Qt API.
>
> I don't know what I can do.
> You should have the same issue with all application managing dates.
>
> My advice is to use format with complete year (7/30/2015) to avoid bad
> interpretation.
>
> --
> You are receiving this mail because:
> You reported the bug.
>

I am testing the following correction.
If the local date format has full year then skrooge will use the local date format
else skrooge will use "dd/MM/yyyy". (Only for date widget)

In you case, you won't have the format corresponding with your locale but it should work.

I take you informed.

Git commit 8c52484dd7079f415faa25aba710baeb457fba4e by Stephane Mankowski.
Committed on 03/08/2015 at 21:01.
Pushed by smankowski into branch 'master'.

Sudden date change from 20XX to 19XX

M  +1    -0    CHANGELOG
M  +10   -3    skgbasegui/kdateedit.cpp
M  +1    -0    skgbasegui/kdateedit.h

http://commits.kde.org/skrooge/8c52484dd7079f415faa25aba710baeb457fba4e

I did the correction described in "Comment 10"

After some research, I've found the reason of difference in the behavior of Skrooge 1 and 2. Just post it here, may be it would be helpful. I use ru_UA.UTF-8 locale.

Skrooge 1 uses KLocale from kdelibs to get localized short date. AFAIK it uses localization data from system. In my case, this results in a 4-digit year (%Y is a yyyy):

[nekit@localhost ~]$ locale d_fmt
%d.%m.%Y

Skrooge 2 uses QLocale for localized short date. Qt used data from ICU, where short date for my locale is dd.MM.yy.

So, there is difference in system locale from glibc and from icu.

Also I found, that about a third of locales in Qt has yy in short date format.

Hi Nikita,

Whatever the local used, the issue comes when the year is written with 2 digits only.
My correction will solve this.
I tested it with ru_UA locale.

Git commit 8bd5db922f3ac0ae03637658070a8bd97f05004e by Stephane Mankowski.
Committed on 06/09/2015 at 20:14.
Pushed by smankowski into branch 'master'.

Sudden date change from 20XX to 19XX

M  +1    -0    CHANGELOG
M  +7    -2    skgbasegui/kdatevalidator.cpp

http://commits.kde.org/skrooge/8bd5db922f3ac0ae03637658070a8bd97f05004e