You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@yahoo.com> on 2010/02/26 07:22:06 UTC

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

Bump.


--- On Wed, 10/14/09, Adrian Crum <ad...@hlmksw.com> wrote:

> From: Adrian Crum <ad...@hlmksw.com>
> Subject: Re: Dates, Times, Timezones, Locales, and OFBiz
> To: dev@ofbiz.apache.org, "user@ofbiz.apache.org" <us...@ofbiz.apache.org>
> Date: Wednesday, October 14, 2009, 1:24 PM
> 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).
> 
>