Enterprise Client Community

Hi Björn,

were you able to reproduce the bug for DateFormat dd.MM.yy?

Best regards
Benjamin

Hi,

ah sorry - of course the Date-Format used by us is dd.MM.yy.

After debugging the client we found the bug:

org.eclnt.client.context.LocalClientConfiguration.s_century19resolution

has a default value of -1 (which is not changed by us) and in org.eclnt.client.controls.impl.CCFormatters.CCDateFormatShort.parse(String, ParsePosition) this value causes the addition of 1900 instead of 2000 which results in the wrong date.

We think it would be a good idea to set this value to a sensible default e.g. "1937"

Just like in JDK format parsing java.text.SimpleDateFormat.subParse(String, int, int, int, boolean, boolean[], ParsePosition, boolean, CalendarBuilder), case: PATTERN_YEAR, see derfaultCenturyStartYear)

Hi Björn,

we just found another little bug: if we set date-format "dd.mm.yy" and use the date-picker entry field to chose a date, e.g. tomorrow, the year is reset from 2017 to 1917.

The same happens for entered dates in the date field. The century for the short year format 'yy' seams to have a wrong value?

Regards
Benjamin

No there is another bug (after this bugfix):

If we use data-format short (english) e.g. (4/7/52)
no date can be entered anymore using the keyboard or
even the prompter.

"Die Eingabe "4/7/52" ist nicht korrekt und wird durch den vorherigen Wert ersetzt. Prüfen Sie ihre Eingabe.

This only occurs if the date-only format is used. If the long version (with timestamp) is used the bug does not occur.