Naveen,
The current OFBiz framework supports a user-selected locale and time
zone. There are places in the UI where those settings are ignored and
date/time strings are hard-coded to the yyyy-MM-dd HH:mm:ss.SSS format.
That was a design decision made by the developer community.
Most of the framework code uses a formatting string constant found in
UtilDateTime.java:
public static final String DATE_TIME_FORMAT = "yyyy-MM-dd HH:mm:ss.SSS";
If you want to change the date/time format, that would be place to do it.
It would be best to have those format strings loaded from a properties
file, so that users like yourself can change it easily - without having
to modify framework code. Anyone wanting to work on that improvement can
submit a patch to Jira and I would be happy to review and commit it.
-Adrian
naveenchanda wrote:
Hi Adrian,
As i am very new to the OFBiz, i cannot able to locate the Timezone settings
for the format of dd-MM-yyyy and also the locale settings for Indonesia.
Please help me to solve my above task.
Thanks,
Naveen Chanda
Adrian Crum wrote:
That email is very old. Since it was written, the framework and Work
Effort application have been improved to support user-selected locale
and time zone.
-Adrian
naveenchanda wrote:
Hi Adrian,
Could you please share the code and files, which is the same issue i am
facing... i need to change the dateformat of the entire application to
dd-MM-yyyy
Please help me to solve my issue.
Waiting for your reply.
Thanks,
Naveen Chanda
Adrian Crum wrote:
I'm going to share what I've learned from building my own calendar
application. Some of this will seem obvious or common-knowledge, but I
want to make sure the subject is covered thoroughly and I also want to
make sure that everyone who is interested in the subject will be on the
same page.
My goal: to develop what I call a "movable calendar" - a set of
date/time
services that will operate correctly no matter what time zone or locale
the user is in.
*** The concept -
OFBiz uses java.sql.Timestamp for storing/retrieving date/time values.
Timestamp is a long data type that contains milliseconds elapsed since
Jan
1, 1970. The time is referenced to UTC. A particular moment in time that
is represented by a Timestamp value can be thought of as a constant, or
that the
value is immutable. The user's timezone or locale does not alter the
Timestamp's value.
In order for a user to interact with a Timezone value in a way that
reflects their timezone and locale, the Timezone value must be converted
to a user-friendly data type - typically a String. Java supplies a good
set of classes that manage Timestamp-to-String and String-to-Timestamp
conversions.
Those classes do all the work of basing the conversions on timezones and
locales - the programmer doesn't have to bother with any of those
details.
As long as the services that handle date/time values always utilize the
user's timezone and locale in conversions, then the goal will be
achieved
- a calendar that moves with the user. It helps to look at it this way:
Entity --> Conversion to String using the user's time zone and locale
-->
UI
UI --> Conversion to Timestamp using the user's time zone and locale -->
Entity
It is very important to understand that all conversions must be run
through the same services, otherwise the date/time value presented to
the
user (or stored in an entity) will be unpredictable.
*** The implementation -
I created two conversion methods:
public static String timeStampToString(Timestamp stamp, TimeZone
tz,
Locale locale);
public static Timestamp stringToTimeStamp(String dateTimeString,
TimeZone tz, Locale locale);
and I made sure that all date/time data in my calendar application is
routed through those two methods. The implementation was successful. A
date/time value I create in one timezone appears in the correct time
when
I switch timezones. In addition, since the conversions utilize the
user's
locale, the
date/time values are displayed/edited in the format I expect to see them
(dd mmm yyyy if I'm in Europe).
