Enterprise Client Community

Using t:calendarfield, with formatmask="short", the century is displayed only with 2 digits.

When a user enters a date (e.g. 4/7/52) it is ambiguous what century to use, so the default choice (using 20 years into future, 80 years into past) is fine, resulting in 1952 for my example.

However when the user enters "4/7/2052", while it is acceptable that the text displayed in the control switches to "04/07/52", the internal date should remain at 2052.

Also when the server sends such a date, clicking "open popup" displays the calendar (where the year is visible as 4 digits) it should also show the correct century. With the popup open, when you press the "Change-year" button quite a few times to arrive at 2052, this should make it into the data that is finally submitted to the server.

regards
Manfred

Hi Manfred,

I completely agree - and see that there is some serious problem with the "short" variant, that may also lead to inconsistency of date input...

Just checking + fixing...

Thanks a lot + regards! Björn

PS: just to re-emphasize for all readers - this is the Swing client! So this bug might have also certain relevance for other "old users"...

OK, issue is fixed.

We now use an own DateFormat which dynamically switches between SHORT and MEDIUM, where before the SHORT dateformat was used.

This means:

01.01.2019 is displayed as "01.01.19"
01.01.1919 is displayed as "01.01.1919"
01.01.2119 is displayed as "01.01.2019"

By default 2 digits numbers are starting with year 2000, but you may explicitly set by client parameter "century19resolution".

This means: dates are displayed and input correctly now. The information about the first 2 digits does not get lost.

BUT: you may reserve a bit more screen space, because also short dates may now also be rendered with a 4 digit year.

The build of this week is just in preparation. I hope to release it overnight.

Regards, Björn

Fix is part of 20170412. - Regards, Björn

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.

...can reproduce, just checking...

Björn

Problem is solved: it occurs with all settings where the medium and the short format are incompatible... Example: in English the short format of today is "5/9/17" and the medium format is "May 9, 1917". Parsing a short date with a medium parser is not possible + vice versa.

So bug is fixed, we now parse with both formats in order to properly understand the value.

The fix has made it in today's update which is available in the afternoon of today.

Thanks + regards! Björn

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

Hi,

could you please check: the "mm" should be "MM" to be the month, otherwise it is the minute.
I tested with "dd.MM.yy" (instead of "dd.mm.yy") and could not find problems.

Regards, Björn

PS: http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html is the one internally used

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,

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

Best regards
Benjamin