Alright.

Regards
Felix

Am Freitag, den 15.02.2008, 16:38 -0800 schrieb Tobias Bocanegra:
> thanks for fixing this.
> i think we should hard-code it to Locale.US for now and see if there
> is a problem with this.
> regards, toby
> 
> On 2/14/08, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > Am Dienstag, den 12.02.2008, 12:53 -0800 schrieb Tobias Bocanegra
> > (JIRA):
> > > [ 
> > > https://issues.apache.org/jira/browse/SLING-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> > >  ]
> > >
> > > Tobias Bocanegra closed SLING-231.
> > > ----------------------------------
> > >
> > >
> > > works. thanks.
> >
> > Not really ;-)
> >
> > I just fixed an issue with the DateParser class, which creates
> > SimpleDateFormat instances using the platform default locale. If this
> > happens to be Locale.US as used by the integration test case, all works
> > fine. If this happens to be something else, like Locale.CH_de like on my
> > system, the test fails.
> >
> > But also this fix is bound for failure: It only hardcodes the locale to
> > used for parsing on the server side without taking into account the
> > locale used to create the test value on the client side. I suggest this
> > should quickly be reviewed, e.g. whether it would make sense to take the
> > javax.servlet.ServletRequest.getLocale() into account.
> >
> > Thanks and Regards
> > Felix
> >
> >
> > >
> > > > ujax post servlet should respect several date formats for 
> > > > @TypeHint="Date"
> > > > --------------------------------------------------------------------------
> > > >
> > > >                 Key: SLING-231
> > > >                 URL: https://issues.apache.org/jira/browse/SLING-231
> > > >             Project: Sling
> > > >          Issue Type: Improvement
> > > >            Reporter: Tobias Bocanegra
> > > >            Assignee: Carsten Ziegeler
> > > >         Attachments: ujax_date_parser.r620038.patch, 
> > > > ujax_date_parser.r620437.patch
> > > >
> > > >   Original Estimate: 0h
> > > >  Remaining Estimate: 0h
> > > >
> > > > for current date properties the property value handler just calls 
> > > > Node.setProperty(String, type) which will result in errors, if the date 
> > > > string is not of the correct jcr specified format.
> > > > suggest to add additional conversion helpers that check a range for 
> > > > date formats to be able to deal with other formats, such as ECMA, etc.
> > >
> >
> >
> 
> 

Reply via email to