Hi Lucas, Yes, I suggest you file a JIRA with your use case.
Yee-Wah Lucas Satabin wrote:
Hi Zee-wah Thanks for the answer. It is also what I thought. I can not however not change the pattern because it is a part of a file name I receive that I must test. Should I open a ticket for this bug? As a workaround I disabled the client validation and I do not have any problem anymore, but I do not have the client message anymore :( Lucas Zee-wah Lee a écrit :Hi Lucas, I was able to reproduce this. The problem is in the client datetime converter, which assumes that years occupy 4 digits. function _subparse (..) case 'y': // year var year = _accumulateNumber(parseContext, 4); So, it parses a string like "981122" and gets year=9811, then runs out of digits for the month and day. This hasn't been a more common problem because there is usually a separator ('/' in en_us), so when the parse encounters the separator char, it doesn't try to consume more characters. In the en_us case, after it parses out year=98, it will fix it to 1998 in _fix2DYear. I'm not familiar with the history of "shortish" in the converter, it may be why the client code assumes 4 characters for years. Tag doc states: The default dateStyle is |shortish|. Shortish is identical to |short| but forces the year to be a full four digits. |dateStyle| defaults to |shortish| if it was not set. If anyone knows if there is a limitation on date time converter regarding 2 digit years, please chime in. Otherwise, this sounds like a bug (workaround: use 4 digit years or separator char). Yee-Wah Lucas Satabin wrote:Hello everybody, I am trying to convert an input into a date using Trinidad. <tr:inputDate rendered="#{col.date}" value="#{co.value}" disabled="#{!col.edit}" required="false"> <tr:convertDateTime pattern="#{col.pattern}" /> </tr:inputDate> It works fine for almost each pattern. I am however facing some problems when the pattern becomes "yyMMdd" In this case, as long as the client validation is allowed. I do not have this problem anymore if I disable the client validation with <client-validation>DISABLED</client-validation> With the client validation enabled, the value is never committed as far as the validation fails. It prints : valid example: 981122 Obviously this example value does not work either. Is this problem known? I searched for this but did not find anything. Thanks in advance Lucas -- Ingénieur diplômé ENSEEIHT (Informatique) Lucas Satabin Entwickler FlexSecure GmbH Industriestr. 12 D-64297 Darmstadt Tel.: +49 (0) 6151 501 23-15 Fax.: +49 (0) 6151 501 23-19 E-mail: sata...@flexsecure.de <mailto:sata...@flexsecure.de> Internet: www.flexsecure.de <http://www.flexsecure.de> Geschäftsführer: Erwin Stallenberger, Markus Ruppert Amtsgericht Darmstadt HRB 8036 Umsatzsteuernummer: DE 214745269
