The way the OFBiz framework is set up, date-time object type conversions
need to be bidirectional. So, either the UtilDateTime methods need to be
used, or the Conversion framework needs to be used. Using a JavaScript
library for date-time object type conversion is bound to cause problems
because its conversions are not a part of the framework.
-Adrian
On 11/1/2011 10:12 PM, Jacques Le Roux wrote:
Also you might be interested by
https://fisheye6.atlassian.com/browse/ofbiz/branches/jquery/framework/widget/templates/htmlFormMacroLibrary.ftl
From where I discovered OFBIZ-3830
Jacques
From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
This change was made in the jQuery branch and merged after at
http://svn.apache.org/viewvc?view=revision&revision=1044503
So I need to search in the jQuery branch. I will do as soon as I will
get a chance.
My better bet would be https://issues.apache.org/jira/browse/OFBIZ-3830
Maybe it's related to this comment I made a this moment, also a bet...
https://issues.apache.org/jira/browse/OFBIZ-3830?focusedCommentId=12882890&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12882890JacquesFrom:
"Adrian Crum" <adrian.c...@sandglass-software.com>> The
renderDateTimeField macro in htmlFormMacroLibrary.ftl ignores the>
framework date-time format settings and formats date-time fields
using> jQuery instead. Two problems with that:>> 1. Even when
shortDateInput = true, the date and time are displayed when> the
value is a Timestamp.> 2. If the value is anything other than a
Timestamp, (java.util.Date or> java.sql.Date) then the field content
is localized, and any attempt to> pass the field content to a service
fails - because there is no way to> convert the string back to the
proper object type.>> Why was this change made?>> -Adrian>
