Author |
Message |
11/04/2017 13:46:52
|
moebus
Power User
Joined: 21/11/2007 12:49:18
Messages: 93
Offline
|
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
|
|
|
11/04/2017 14:10:26
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5521
Offline
|
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"...
|
Björn Müller, CaptainCasa GmbH |
|
|
11/04/2017 15:12:52
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5521
Offline
|
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
|
Björn Müller, CaptainCasa GmbH |
|
|
12/04/2017 05:00:26
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5521
Offline
|
Fix is part of 20170412. - Regards, Björn
|
Björn Müller, CaptainCasa GmbH |
|
|
08/05/2017 10:44:43
|
bjung
Joined: 05/10/2015 14:01:19
Messages: 4
Offline
|
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.
|
Filename |
captain_bug.png |
Download
|
Description |
Left date-field (with timestamp) is working fine, right one leads to error in client validation |
Filesize |
36 Kbytes
|
Downloaded: |
541 time(s) |
|
|
|
08/05/2017 11:49:07
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5521
Offline
|
...can reproduce, just checking...
Björn
|
Björn Müller, CaptainCasa GmbH |
|
|
08/05/2017 12:06:53
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5521
Offline
|
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
|
Björn Müller, CaptainCasa GmbH |
|
|
01/06/2017 05:49:12
|
bjung
Joined: 05/10/2015 14:01:19
Messages: 4
Offline
|
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
|
|
|
01/06/2017 11:24:52
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5521
Offline
|
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
|
Björn Müller, CaptainCasa GmbH |
|
|
01/06/2017 14:59:54
|
bjung
Joined: 05/10/2015 14:01:19
Messages: 4
Offline
|
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)
|
|
|
13/06/2017 12:20:08
|
bjung
Joined: 05/10/2015 14:01:19
Messages: 4
Offline
|
Hi Björn,
were you able to reproduce the bug for DateFormat dd.MM.yy?
Best regards
Benjamin
|
|
|
|