RichCalendar: 60 to 2060, 70 to 1970... why?

[luxspes]

Hi!
I have a rich calendar configured like this:

<rich:calendar id="rfcFecha" datePattern="yyMMdd" styleClass="preserveFocus enterToTab" enableManualInput="true" tabindex="2" value="#{buscaContribuyenteWeb.rfcFecha}" rendered="true">
 <f:convertDateTime pattern="yyMMdd" />
 <a4j:support event="onblur"/>
 </rich:calendar>

If the user writes 600210 and the user clicks the little calendar button to show the popup, he can see that the date has been translated to "February 10 of 2060" but if he writes 700210 it is translated in to "February 10 of 1970".

I want to be able to control that, so that if the date is "after today" it translates it to 19xx, and if its before today, it translates it to 20xx.

How can I achieve that?

[luxspes]

This behavior is, by the way, not consistent with the way Java works:

String str_date="600210";
java.text.DateFormat formatter ;
java.util.Date date ;
formatter = new java.text.SimpleDateFormat("yyMMdd");
date = (java.util.Date)formatter.parse(str_date);
System.out.println("The date is " +date );

Prints: "The date is Wed Feb 10 00:00:00 CST 1960" (and not 2060 as the richcalendar does).

OTOH this "wrong" conversion seems to be happening "client-side" in javascript, before anything is sent to java... maybe it is a bug in the date client side string to date conversion of the richfaces calendar?

[luxspes]

Oh, I almost forgot, I am using Richfaces 3.3.1, JDK 1.6u14, Seam 2.1.1, Tomcat 6.0.20 and Firefox 3.5.5

[luxspes]

Found the error, it is at 3.3.1.GA\ui\calendar\src\main\resources\org\richfaces\renderkit\html\scripts\calendar.js:

At the Richfaces.Calendar.parseDate = function(dateString, pattern, monthNames, monthNamesShort) method (line 394 of the file):

var yy = parseInt(match[y],10); if (isNaN(yy)) return null; else if (yy<70) yy+=2000; else if (yy<100) yy+=1900;

I really would like to know why it was implemented that way, when java.text.SimpleDateFormat clearly does NOT work that way, and this only has the effect of breaking the principle of less astonishment.

Guess it is time to create a JIRA...

[luxspes]

And so RF-8136 is created

[ilya_shaikovsky]

Actually it just made like you described by design. And the behavior will not be changed at least for 3.3.x because of backward compatibility for stabilization branch.

[luxspes]

"ilya_shaikovsky" wrote:
Actually it just made like you described by design.

It is made like that By design? Why? With the purpose of satisfying what requirement? Maybe with the explicit self defeating purpose of becoming not compatible with Java? (I really dislike when I am told that something is "by design" but does not explain what is the "design advantage or user requirement" that is satisfied by such design).

"ilya_shaikovsky" wrote:

And the behavior will not be changed at least for 3.3.x because of backward compatibility for stabilization branch.

For Richfaces 4.0 it would be a good idea to make the 19xx/20xx range configurable but for the 3.3.x branch you could include a boolean attribute to make it possible to turn this incompatibility off...

Would you at least be so kind as to explain why do you explicitly brake compatibility with Java? it makes no sense to me at all

[ilya_shaikovsky]

actually we designed this in order to choose date which nearest to current more fast while using formats with short year definitions.

you could add behavior you need by just this simple code:

ondateselect="if (event.rich.date.getFullYear()<2000) event.rich.date.setYear(event.rich.date.getFullYear()+100)"

but with your pattern I have to give you notice that even if you will choose 1999 year from popup and apply it it will be passed to input like 990210 and on calendar open it will be parsed as 2099 again and made selected.

[ilya_shaikovsky]

and b.t.w.

 <rich:calendar value="#{calendarBean.selectedDate}"
 locale="#{calendarBean.locale}" enableManualInput="true"
 popup="#{calendarBean.popup}"
 datePattern="yyMMdd"
 showApplyButton="#{calendarBean.showApply}" cellWidth="24px" cellHeight="22px" style="width:200px">
 </rich:calendar>
 <a4j:commandButton value="rer" reRender="rer"/>
 <h:outputText value="#{calendarBean.selectedDate}" id="rer">
 <f:convertDateTime pattern="MMM,d yyyy"/>
 </h:outputText>

this returns also 1980 to output after button pressed and year typed as 80

but this

 <rich:calendar value="#{calendarBean.selectedDate}"
 locale="#{calendarBean.locale}" enableManualInput="true"
 popup="#{calendarBean.popup}"
 datePattern="yyMMdd"
 showApplyButton="#{calendarBean.showApply}" cellWidth="24px" cellHeight="22px" style="width:200px" ondateselect="if (event.rich.date.getFullYear()&lt;2000) event.rich.date.setYear(event.rich.date.getFullYear()+100)">
 </rich:calendar>
 <a4j:commandButton value="rer" reRender="rer"/>
 <h:outputText value="#{calendarBean.selectedDate}" id="rer">
 <f:convertDateTime pattern="MMM,d yyyy"/>
 </h:outputText>

will open calendar at 2080 with the same input but after submit output will show still 1980.

selectedDate - has Date type. and no additional converters used.

[luxspes]

"ilya_shaikovsky" wrote:


but with your pattern I have to give you notice that even if you will choose 1999 year from popup and apply it it will be passed to input like 990210 and on calendar open it will be parsed as 2099 again and made selected.

I am not sure I understand what you mean, but that behaviour sounds inconsistent and "like a bug" to me...

[luxspes]

"ilya_shaikovsky" wrote:
and b.t.w.

will open calendar at 2080 with the same input but after submit output will show still 1980.

And... such... inconsistent behavior... is not a bug to you?

[ilya_shaikovsky]

In this case Calendar just can't know which date you want to open. Especially when enablemanualinput attribute set to true. calendar parses the current input value before opening in order to select date in in opened popup. And with yy pattern we can't know what do you need to see.

yes you selected the date and want to see it after opening.. but if you will modify the input(erase one "9" and add it back)? or even type the date from the begging manually? The behavior should be consistent for all cases. We can't ignore input value so we parsing it and getting either the 19xx values which you dislike by default or 20xx with my workaround. But always using the same algorithm.

[ilya_shaikovsky]

you could disable switching calendar more that +-100 years in order to work with such pattern correctly.