Re: Dates, Times, Timezones, Locales, and OFBiz

[Adrian Crum]

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).