Apache OFBiz Time Zone Support Strategy

[Adrian Crum]

I'm starting a new thread for us to discuss the User-Selected Time Zone Support strategy. The
previous thread regarding the Workeffort Calendar Progress started to expand into other subjects and
strayed away from the original subject, so I thought it would be best if we separated the Time Zone
support discussion into its own thread.

My hope is that we can use this thread to brainstorm and come up with a general implementation
strategy and maybe even assume/assign tasks to achieve the end result.

*** The Goal: To have OFBiz support a user-selected time zone. Once a user has selected a time zone,
nearly all of the date/time data will be displayed/entered referenced to that time zone. Some system
date/time data may be excluded from this goal.

In the Workeffort Calendar thread, there was some discussion about how the date/time data should be
formatted. I propose we leave that detail out of this discussion so that we don't get diverted. How
the date/time data is formatted doesn't affect this thread's goal or its strategy.

*** The Strategy (Some of this has been implemented already - it is included here to make sure we're
all on the same page) :

1. Provide a means for the user to select a time zone.
2. Persist the user's time zone selection and make a corresponding java.util.TimeZone object
generally available
3. Provide a set of utility methods that take the user's TimeZone object as a parameter to perform
date/time conversions, date/time arithmetic, etc.
4. Modify some of the low-level framework code to accept an optional TimeZone object, then pass that
object on to the utility methods mentioned in #3. A typical example would be the
simpleTypeConvert(...) method in ObjectType.java - where it handles Timestamp conversions.
5. Modify the higher-level code to call the low-level code using the user's TimeZone object. Replace
embedded date/time conversions/arithmetic with utility method calls.

Please feel free to comment on/add to the stragey items.

Steps #1 and #2 have been implemented recently. (Btw, the patch in OFBIZ-1126 needs to be committed
to fix a bug).

Step #3 is partially implemented in the recent changes to UtilDateTime.java.

Step #4 has not started yet. This step requires the expertise of developers who are skilled with the
service engine, widgets, and such.

Step #5 is the crucial one. Every step prior to this one will be backwards compatible. Step #5 is
the "plunge forward" - we do it all or not at all.

I'm thinking we can start off by discussing and improving upon this general strategy, then move on
to specific tasks, etc. Let's hold off on starting Jira issues, etc until the community has had time
to comment and reach a consensus.

Comments are encouraged and welcome.

-Adrian

[Daniel Martínez-4]

I am right now developing support for locale formats in a local ofbiz
copy. I know this thread is not for this, but the steps (as Adrian put
them) for it are very similar to Timezones'

I have encountered a problem with performFind-style forms/services for
timezones and date format to be implemented.

Normally, a receiver from a form will be a service or a method (java,
bsh...). A service will convert the date correctly to the server
timezone by means of simpleTypeConvert() while another method (like
ShoppingCart's methods) will have to be modified to convert the dates.

But performFind does not have knowledge of the type of the fields. It
just looks for the suffixes and creates an SQL statement accordingly.
There is no way to know if there is a date in the "inputFields" list.

Does anyone know the best way to workaround/fix this problem? Maybe
another suffix for the forms with the type of the field?

Adrian, nothing to comment about your planning, I think it is right.

Thanks,
--
Daniel

Adrian Crum escribió:

> I'm starting a new thread for us to discuss the User-Selected Time
> Zone Support strategy. The previous thread regarding the Workeffort
> Calendar Progress started to expand into other subjects and strayed
> away from the original subject, so I thought it would be best if we
> separated the Time Zone support discussion into its own thread.
>
> My hope is that we can use this thread to brainstorm and come up with
> a general implementation strategy and maybe even assume/assign tasks
> to achieve the end result.
>
> *** The Goal: To have OFBiz support a user-selected time zone. Once a
> user has selected a time zone, nearly all of the date/time data will
> be displayed/entered referenced to that time zone. Some system
> date/time data may be excluded from this goal.
>
> In the Workeffort Calendar thread, there was some discussion about how
> the date/time data should be formatted. I propose we leave that detail
> out of this discussion so that we don't get diverted. How the
> date/time data is formatted doesn't affect this thread's goal or its
> strategy.
>
> *** The Strategy (Some of this has been implemented already - it is
> included here to make sure we're all on the same page) :
>
> 1. Provide a means for the user to select a time zone.
> 2. Persist the user's time zone selection and make a corresponding
> java.util.TimeZone object generally available
> 3. Provide a set of utility methods that take the user's TimeZone
> object as a parameter to perform date/time conversions, date/time
> arithmetic, etc.
> 4. Modify some of the low-level framework code to accept an optional
> TimeZone object, then pass that object on to the utility methods
> mentioned in #3. A typical example would be the simpleTypeConvert(...)
> method in ObjectType.java - where it handles Timestamp conversions.
> 5. Modify the higher-level code to call the low-level code using the
> user's TimeZone object. Replace embedded date/time
> conversions/arithmetic with utility method calls.
>

> Please feel free to comment on/add to the stragey items.
>
> Steps #1 and #2 have been implemented recently. (Btw, the patch in
> OFBIZ-1126 needs to be committed to fix a bug).
>
> Step #3 is partially implemented in the recent changes to
> UtilDateTime.java.
>
> Step #4 has not started yet. This step requires the expertise of
> developers who are skilled with the service engine, widgets, and such.
>
> Step #5 is the crucial one. Every step prior to this one will be
> backwards compatible. Step #5 is the "plunge forward" - we do it all
> or not at all.

>
> I'm thinking we can start off by discussing and improving upon this
> general strategy, then move on to specific tasks, etc. Let's hold off
> on starting Jira issues, etc until the community has had time to
> comment and reach a consensus.
>
> Comments are encouraged and welcome.
>
> -Adrian
>

[Jacopo Cappellato]

Daniel,

Daniel Martínez wrote:

> I am right now developing support for locale formats in a local ofbiz
> copy. I know this thread is not for this, but the steps (as Adrian put
> them) for it are very similar to Timezones'
>
> I have encountered a problem with performFind-style forms/services for
> timezones and date format to be implemented.
>
> Normally, a receiver from a form will be a service or a method (java,
> bsh...). A service will convert the date correctly to the server
> timezone by means of simpleTypeConvert() while another method (like
> ShoppingCart's methods) will have to be modified to convert the dates.
>
> But performFind does not have knowledge of the type of the fields. It
> just looks for the suffixes and creates an SQL statement accordingly.
> There is no way to know if there is a date in the "inputFields" list.
>

I think you are right; there is currently another issue about the
formatting of numbers with decimals affecting the performFind service:

https://issues.apache.org/jira/browse/OFBIZ-221

> Does anyone know the best way to workaround/fix this problem? Maybe
> another suffix for the forms with the type of the field?
>

Or two new input parameters: local and timezone of the incoming data

> Adrian, nothing to comment about your planning, I think it is right.
>
> Thanks,
> --
> Daniel
>
> Adrian Crum escribió:
>> I'm starting a new thread for us to discuss the User-Selected Time
>> Zone Support strategy. The previous thread regarding the Workeffort
>> Calendar Progress started to expand into other subjects and strayed
>> away from the original subject, so I thought it would be best if we
>> separated the Time Zone support discussion into its own thread.
>>
>> My hope is that we can use this thread to brainstorm and come up with
>> a general implementation strategy and maybe even assume/assign tasks
>> to achieve the end result.
>>
>> *** The Goal: To have OFBiz support a user-selected time zone. Once a
>> user has selected a time zone, nearly all of the date/time data will
>> be displayed/entered referenced to that time zone. Some system
>> date/time data may be excluded from this goal.
>>
>> In the Workeffort Calendar thread, there was some discussion about how
>> the date/time data should be formatted. I propose we leave that detail
>> out of this discussion so that we don't get diverted. How the
>> date/time data is formatted doesn't affect this thread's goal or its
>> strategy.
>>
>> *** The Strategy (Some of this has been implemented already - it is
>> included here to make sure we're all on the same page) :
>>
>> 1. Provide a means for the user to select a time zone.
>> 2. Persist the user's time zone selection and make a corresponding
>> java.util.TimeZone object generally available
>> 3. Provide a set of utility methods that take the user's TimeZone
>> object as a parameter to perform date/time conversions, date/time
>> arithmetic, etc.
>> 4. Modify some of the low-level framework code to accept an optional
>> TimeZone object, then pass that object on to the utility methods
>> mentioned in #3. A typical example would be the simpleTypeConvert(...)
>> method in ObjectType.java - where it handles Timestamp conversions.
>> 5. Modify the higher-level code to call the low-level code using the
>> user's TimeZone object. Replace embedded date/time
>> conversions/arithmetic with utility method calls.
>>
>
>> Please feel free to comment on/add to the stragey items.
>>
>> Steps #1 and #2 have been implemented recently. (Btw, the patch in
>> OFBIZ-1126 needs to be committed to fix a bug).
>>
>> Step #3 is partially implemented in the recent changes to
>> UtilDateTime.java.
>>
>> Step #4 has not started yet. This step requires the expertise of
>> developers who are skilled with the service engine, widgets, and such.
>>
>> Step #5 is the crucial one. Every step prior to this one will be
>> backwards compatible. Step #5 is the "plunge forward" - we do it all
>> or not at all.
>
>> I'm thinking we can start off by discussing and improving upon this
>> general strategy, then move on to specific tasks, etc. Let's hold off
>> on starting Jira issues, etc until the community has had time to
>> comment and reach a consensus.
>>
>> Comments are encouraged and welcome.
>>
>> -Adrian
>>

[Michael Jensen-5]

Out of curiosity, would this new strategy also take into account
Daylight Savings time?  Being an inexperienced java programmer, I'm not
sure if this is built into java.util.TimeZone already or if it would
have to be built into ofbiz.

Mike


Adrian Crum wrote:

> I'm starting a new thread for us to discuss the User-Selected Time Zone
> Support strategy. The previous thread regarding the Workeffort Calendar
> Progress started to expand into other subjects and strayed away from the
> original subject, so I thought it would be best if we separated the Time
> Zone support discussion into its own thread.
>
> My hope is that we can use this thread to brainstorm and come up with a
> general implementation strategy and maybe even assume/assign tasks to
> achieve the end result.
>
> *** The Goal: To have OFBiz support a user-selected time zone. Once a
> user has selected a time zone, nearly all of the date/time data will be
> displayed/entered referenced to that time zone. Some system date/time
> data may be excluded from this goal.
>
> In the Workeffort Calendar thread, there was some discussion about how
> the date/time data should be formatted. I propose we leave that detail
> out of this discussion so that we don't get diverted. How the date/time
> data is formatted doesn't affect this thread's goal or its strategy.
>
> *** The Strategy (Some of this has been implemented already - it is
> included here to make sure we're all on the same page) :
>
> 1. Provide a means for the user to select a time zone.
> 2. Persist the user's time zone selection and make a corresponding
> java.util.TimeZone object generally available
> 3. Provide a set of utility methods that take the user's TimeZone object
> as a parameter to perform date/time conversions, date/time arithmetic, etc.
> 4. Modify some of the low-level framework code to accept an optional
> TimeZone object, then pass that object on to the utility methods
> mentioned in #3. A typical example would be the simpleTypeConvert(...)
> method in ObjectType.java - where it handles Timestamp conversions.
> 5. Modify the higher-level code to call the low-level code using the
> user's TimeZone object. Replace embedded date/time
> conversions/arithmetic with utility method calls.
>
> Please feel free to comment on/add to the stragey items.
>
> Steps #1 and #2 have been implemented recently. (Btw, the patch in
> OFBIZ-1126 needs to be committed to fix a bug).
>
> Step #3 is partially implemented in the recent changes to
> UtilDateTime.java.
>
> Step #4 has not started yet. This step requires the expertise of
> developers who are skilled with the service engine, widgets, and such.
>
> Step #5 is the crucial one. Every step prior to this one will be
> backwards compatible. Step #5 is the "plunge forward" - we do it all or
> not at all.
>
> I'm thinking we can start off by discussing and improving upon this
> general strategy, then move on to specific tasks, etc. Let's hold off on
> starting Jira issues, etc until the community has had time to comment
> and reach a consensus.
>
> Comments are encouraged and welcome.
>
> -Adrian
>

--
Millcreek Systems, Inc.
P.O. Box 9835
Salt Lake City, Utah 84109
Phone: [phone]
Skype: millcreeksys (http://millcreeksys.com/skype/)

[Adrian Crum]

Michael,

Yes, Daylight Saving Time is accomodated. The utility methods mentioned in step #3 use the
java.util.TimeZone and java.util.Calendar classes - which handle all of the messy calendar and time
keeping details.

Try out the  we_svc_bsh_ftl.patch patch in OFBIZ-1089
(https://issues.apache.org/jira/browse/OFBIZ-1089). You'll see the strategy I proposed being used in
the Workeffort Calendar.

-Adrian

Michael Jensen wrote:

> Out of curiosity, would this new strategy also take into account
> Daylight Savings time?  Being an inexperienced java programmer, I'm not
> sure if this is built into java.util.TimeZone already or if it would
> have to be built into ofbiz.
>
> Mike
>
>
> Adrian Crum wrote:
>
>>I'm starting a new thread for us to discuss the User-Selected Time Zone
>>Support strategy. The previous thread regarding the Workeffort Calendar
>>Progress started to expand into other subjects and strayed away from the
>>original subject, so I thought it would be best if we separated the Time
>>Zone support discussion into its own thread.
>>
>>My hope is that we can use this thread to brainstorm and come up with a
>>general implementation strategy and maybe even assume/assign tasks to
>>achieve the end result.
>>
>>*** The Goal: To have OFBiz support a user-selected time zone. Once a
>>user has selected a time zone, nearly all of the date/time data will be
>>displayed/entered referenced to that time zone. Some system date/time
>>data may be excluded from this goal.
>>
>>In the Workeffort Calendar thread, there was some discussion about how
>>the date/time data should be formatted. I propose we leave that detail
>>out of this discussion so that we don't get diverted. How the date/time
>>data is formatted doesn't affect this thread's goal or its strategy.
>>
>>*** The Strategy (Some of this has been implemented already - it is
>>included here to make sure we're all on the same page) :
>>
>>1. Provide a means for the user to select a time zone.
>>2. Persist the user's time zone selection and make a corresponding
>>java.util.TimeZone object generally available
>>3. Provide a set of utility methods that take the user's TimeZone object
>>as a parameter to perform date/time conversions, date/time arithmetic, etc.
>>4. Modify some of the low-level framework code to accept an optional
>>TimeZone object, then pass that object on to the utility methods
>>mentioned in #3. A typical example would be the simpleTypeConvert(...)
>>method in ObjectType.java - where it handles Timestamp conversions.
>>5. Modify the higher-level code to call the low-level code using the
>>user's TimeZone object. Replace embedded date/time
>>conversions/arithmetic with utility method calls.
>>
>>Please feel free to comment on/add to the stragey items.
>>
>>Steps #1 and #2 have been implemented recently. (Btw, the patch in
>>OFBIZ-1126 needs to be committed to fix a bug).
>>
>>Step #3 is partially implemented in the recent changes to
>>UtilDateTime.java.
>>
>>Step #4 has not started yet. This step requires the expertise of
>>developers who are skilled with the service engine, widgets, and such.
>>
>>Step #5 is the crucial one. Every step prior to this one will be
>>backwards compatible. Step #5 is the "plunge forward" - we do it all or
>>not at all.
>>
>>I'm thinking we can start off by discussing and improving upon this
>>general strategy, then move on to specific tasks, etc. Let's hold off on
>>starting Jira issues, etc until the community has had time to comment
>>and reach a consensus.
>>
>>Comments are encouraged and welcome.
>>
>>-Adrian
>>
>
>

[Daniel Martínez-4]

Jacopo Cappellato escribió:
> I think you are right; there is currently another issue about the
> formatting of numbers with decimals affecting the performFind service:
>
> https://issues.apache.org/jira/browse/OFBIZ-221
Thanks, maybe we could fix this too :)
>
>> Does anyone know the best way to workaround/fix this problem? Maybe
>> another suffix for the forms with the type of the field?
>>
>
> Or two new input parameters: local and timezone of the incoming data
AFAIK these data can be get from the service context.

From the prepareField description:

// Strip the "_suffix" off of the parameter name and
        // build a three-level map of values keyed by fieldRoot name,
        //    fld0 or fld1,  and, then, "op" or "value"
        // ie. id
        //  - fld0
        //      - op:like
        //      - value:abc
        //  - fld1 (if there is a range)
        //      - op:lessThan
        //      - value:55 (note: these two "flds" wouldn't really go
together)
        // Also note that op/fld can be in any order. (eg.
id_fld1_equals or id_equals_fld1)
        // Note that "normalizedFields" will contain values other than those
        // Contained in the associated entity.
        // Those extra fields will be ignored in the second half of this
method.

p.e. the form to search workEfforts has this kind of fields:

estimatedStartDate_fld0_value - estimatedStartDate_fld0_op - estimatedStartDate_fld1_value


Of course, estimatedStartDate_fld? are dates and should be converted to
the server timezone/format, but prepareFind/prepareField/performFind do
not know about it

What I propose is adding another optional suffix which can be _date or
_number, so performFind can use it as a condition to convert these
fields from the localized/timezoned original data, so the fields will be:

estimatedStartDate_fld0_value_date - estimatedStartDate_fld0_op - estimatedStartDate_fld1_value_date

WDYT?

Regards,
--
Daniel

[Jacques Le Roux]

Adrian,

For now this strategy seems fine to me. I have to think more about it and especially to look at related code.

Besides, I promise to have a look, and hopefully commit, OFBIZ-642 tomorrow ;o)

Jacques

De : "Adrian Crum" <[hidden email]>

> I'm starting a new thread for us to discuss the User-Selected Time Zone Support strategy. The
> previous thread regarding the Workeffort Calendar Progress started to expand into other subjects and
> strayed away from the original subject, so I thought it would be best if we separated the Time Zone
> support discussion into its own thread.
>
> My hope is that we can use this thread to brainstorm and come up with a general implementation
> strategy and maybe even assume/assign tasks to achieve the end result.
>
> *** The Goal: To have OFBiz support a user-selected time zone. Once a user has selected a time zone,
> nearly all of the date/time data will be displayed/entered referenced to that time zone. Some system
> date/time data may be excluded from this goal.
>
> In the Workeffort Calendar thread, there was some discussion about how the date/time data should be
> formatted. I propose we leave that detail out of this discussion so that we don't get diverted. How
> the date/time data is formatted doesn't affect this thread's goal or its strategy.
>
> *** The Strategy (Some of this has been implemented already - it is included here to make sure we're
> all on the same page) :
>
> 1. Provide a means for the user to select a time zone.
> 2. Persist the user's time zone selection and make a corresponding java.util.TimeZone object
> generally available
> 3. Provide a set of utility methods that take the user's TimeZone object as a parameter to perform
> date/time conversions, date/time arithmetic, etc.
> 4. Modify some of the low-level framework code to accept an optional TimeZone object, then pass that
> object on to the utility methods mentioned in #3. A typical example would be the
> simpleTypeConvert(...) method in ObjectType.java - where it handles Timestamp conversions.
> 5. Modify the higher-level code to call the low-level code using the user's TimeZone object. Replace
> embedded date/time conversions/arithmetic with utility method calls.
>
> Please feel free to comment on/add to the stragey items.
>
> Steps #1 and #2 have been implemented recently. (Btw, the patch in OFBIZ-1126 needs to be committed
> to fix a bug).
>
> Step #3 is partially implemented in the recent changes to UtilDateTime.java.
>
> Step #4 has not started yet. This step requires the expertise of developers who are skilled with the
> service engine, widgets, and such.
>
> Step #5 is the crucial one. Every step prior to this one will be backwards compatible. Step #5 is
> the "plunge forward" - we do it all or not at all.
>
> I'm thinking we can start off by discussing and improving upon this general strategy, then move on
> to specific tasks, etc. Let's hold off on starting Jira issues, etc until the community has had time
> to comment and reach a consensus.
>
> Comments are encouraged and welcome.
>
> -Adrian
>

[Adrian Crum]

Just a quick update on this...

Step 3 is finished.

Step 4 is nearly complete. I submitted some patches to Jira
(https://issues.apache.org/jira/browse/OFBIZ-1164 and https://issues.apache.org/jira/browse/OFBIZ-1170).

I did the best I can do on OFBIZ-1164. Working on the service engine and other core code was a
little over my head. I have time zone support mostly working, but I've run into a brick wall. If
time zone support is to be included in the project, then someone with experience in the service
engine/rendering code needs to step in and help out.

Step 5 has begun with the Workeffort Calendar. A patch has been submitted to Jira
(https://issues.apache.org/jira/browse/OFBIZ-1089) that demonstrates how it all works. If you apply
the patches from OFBIZ-1089, OFBIZ-1164, and OFBIZ-1170 to your local copy, then you can see how
well the time zone support works in the Workeffort Calendar. The only problem is a few screens still
default to the server's time zone - which is caused by the unfinished work that I mentioned in Step 4.

At this point in time I've done all I can do. We just need someone to help with finishing the patch
in OFBIZ-1164, then have the patches in OFBIZ-1164 and OFBIZ-1170 committed.

-Adrian


Adrian Crum wrote:

> I'm starting a new thread for us to discuss the User-Selected Time Zone
> Support strategy. The previous thread regarding the Workeffort Calendar
> Progress started to expand into other subjects and strayed away from the
> original subject, so I thought it would be best if we separated the Time
> Zone support discussion into its own thread.
>
> My hope is that we can use this thread to brainstorm and come up with a
> general implementation strategy and maybe even assume/assign tasks to
> achieve the end result.
>
> *** The Goal: To have OFBiz support a user-selected time zone. Once a
> user has selected a time zone, nearly all of the date/time data will be
> displayed/entered referenced to that time zone. Some system date/time
> data may be excluded from this goal.
>
> In the Workeffort Calendar thread, there was some discussion about how
> the date/time data should be formatted. I propose we leave that detail
> out of this discussion so that we don't get diverted. How the date/time
> data is formatted doesn't affect this thread's goal or its strategy.
>
> *** The Strategy (Some of this has been implemented already - it is
> included here to make sure we're all on the same page) :
>
> 1. Provide a means for the user to select a time zone.
> 2. Persist the user's time zone selection and make a corresponding
> java.util.TimeZone object generally available
> 3. Provide a set of utility methods that take the user's TimeZone object
> as a parameter to perform date/time conversions, date/time arithmetic, etc.
> 4. Modify some of the low-level framework code to accept an optional
> TimeZone object, then pass that object on to the utility methods
> mentioned in #3. A typical example would be the simpleTypeConvert(...)
> method in ObjectType.java - where it handles Timestamp conversions.
> 5. Modify the higher-level code to call the low-level code using the
> user's TimeZone object. Replace embedded date/time
> conversions/arithmetic with utility method calls.
>
> Please feel free to comment on/add to the stragey items.
>
> Steps #1 and #2 have been implemented recently. (Btw, the patch in
> OFBIZ-1126 needs to be committed to fix a bug).
>
> Step #3 is partially implemented in the recent changes to
> UtilDateTime.java.
>
> Step #4 has not started yet. This step requires the expertise of
> developers who are skilled with the service engine, widgets, and such.
>
> Step #5 is the crucial one. Every step prior to this one will be
> backwards compatible. Step #5 is the "plunge forward" - we do it all or
> not at all.
>
> I'm thinking we can start off by discussing and improving upon this
> general strategy, then move on to specific tasks, etc. Let's hold off on
> starting Jira issues, etc until the community has had time to comment
> and reach a consensus.
>
> Comments are encouraged and welcome.
>
> -Adrian
>
>