myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yee-wah Lee <>
Subject Re: [Trinidad] tr:convertDateTime, pattern and client validation
Date Tue, 21 Jul 2009 18:12:42 GMT
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).


Lucas Satabin wrote:
> Hello everybody,
> I am trying to convert an input into a date using Trinidad.
> <tr:inputDate rendered="#{}"
>                          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: <>
> Internet: <>
> Geschäftsführer:
> Erwin Stallenberger, Markus Ruppert
> Amtsgericht Darmstadt HRB 8036
> Umsatzsteuernummer: DE 214745269

View raw message