Author |
Message |
|
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.
|
|
|