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...@hlmksw.com> on 2007/06/12 01:31:31 UTC

Re: [OFBiz] Users - Party and Timezones

Okay, the UtilDateTime.java class has been updated to support locales and time zones. That is the 
first step toward addressing the issue in this thread.

Now the question is, how and where do we persist the time zone? Vinay's original question implied 
(and I may be wrong) that he needed to assign time zones to parties. My use of time zones is more 
user-oriented (for an online calendar program). This same type of use can be found in the Workeffort 
calendar application.

So, I see two uses for time zone info:
   1. It can be persisted in the Party entity so that you can know the time zone of another party.
   2. An OFBiz user can select a time zone to control the display of calendar data.

Example: I log into OFBiz and set my time zone to control the display of calendar data (#2). I check 
my calendar and see a reminder to call a customer. Then I look in the customer's file to see what 
time zone they are in so I will know the best time to call (#1).

Jira issue OFBIZ-2 (https://issues.apache.org/jira/browse/OFBIZ-2) contains a partially-completed 
implementation of #1.

For #2 I was thinking of adding a time zone drop-down list under the current locale drop-down list. 
Clicking the existing Set button would update the user's locale AND time zone. The user's current 
time zone selection would be handled in the same way as their locale: it would be persisted in the 
UserLogin entity, and it can be retrieved via the session attributes.

What do you think?

-Adrian

Adrian Crum wrote:
> I'm resurrecting this discussion because I have run into this issue also 
> and I think it needs to be discussed again.
> 
> To recap: OFBiz defaults to the timezone and locale of the server when 
> handling dates and times. This can be a problem if a user is accessing 
> OFBiz from outside the server's timezone/locale.
> 
> What I've learned so far: java.util.Date stores the date/time as 
> milliseconds since Jan 1, 1970. The date referenced is UTC. How the 
> date/time is presented to the user depends upon the timezone and locale 
> being used in Java code.
> 
> OFBiz's UtilDateTime class uses the Java Date and Calendar classes 
> without regard to a user's timezone or locale. UtilDateTime simply uses 
> the server's locale and timezone. Java's Calendar class is able to 
> convert the date and time correctly if it is initialized with the 
> correct timezone and locale.
> 
> I haven't researched how the various libraries OFBiz uses handle this 
> issue.
> 
> There is an outstanding Jira issue that addresses this: 
> https://issues.apache.org/jira/browse/OFBIZ-2. Thanks to Jacques for 
> pointing that out.
> 
> I duplicated that work in my local copy because I didn't know someone 
> had already done it. I ended up copying UtilDateTime to a new class and 
> I re-wrote it to solve this problem. I'm in the process of using it now. 
> Now that I'm aware of Vinay's patch, I'll probably use it instead.
> 
> Implementing this change in the main project raises many issues and 
> potential pitfalls - particularly with backward compatibility and legacy 
> code.
> 
> So, there is a solution to the problem, but I don't know how we can get 
> it into the project.
> 
> -Adrian
> 
> 
> Chris Howe wrote:
> 
>> I think this does bring up two issues.  The first
>> being that the server should be storing and
>> determining times in UTC, while displaying them in the
>> local time of the client browser.  I know there are
>> scripts available to do this through javascript.  The
>> second issue is making more use of the
>> WebUserPreference Entity.  I don't believe the
>> WebUserPreference is currently being used for anything
>> or has been developed into anything yet.  There is a
>> slight issue with it's primary key as using
>> UserLoginId, partyId, and webPreferenceTypeId is the
>> same as using UserLoginId and webPreferenceTypeId
>> since multiple partyIds cannot have the same
>> UserLoginId.  This entity would also require a value
>> field to be of any use in settings.  The only reason
>> why I bring up the issue of webUserPreference is that
>> you could store a userPreference override of detecting
>> the local browser time.  Not to mention development
>> would help bolster use in things like userLogin css
>> overrides.  But again, it requires a value field to be
>> of any use.
>>
>> ===============David Kunkel wrote:
>>
>> CJ
>>
>> I'm guessing you mean for the time zone data to mostly
>> to be used in
>> scheduling... For example:
>>
>> Have a local representation of the time the company
>> planned the video
>> conference.
>>
>> See the local time that an e-mail arrived.
>>
>> Can you expand on any other uses you've considered?
>>
>> Is there any way this information could be
>> automatically obtained from
>> the browser during the session, rather than something
>> that would require
>> specifically setting. If so, would we really want it
>> added to the
>> datamodel?
>>
>> Thanks
>>
>>
>>
>> On Sun, 2006-01-22 at 21:13 +0000, Charles Johnson
>> wrote:
>>
>>> Perhaps i shouldn't have volunteered that suggestion
>>
>>
>> as i'm not very
>>
>>> familiar with the ER yet. The reason i made it is
>>
>>
>> that a Person can only
>>
>>> be unitary and other entities may span multiple time
>>
>>
>> zones.
>>
>>> CJ
>>>
>>> David E. Jones wrote:
>>>
>>>
>>>> Why Person? This would imply that the timezone
>>
>>
>> doesn't apply to other types of parties, for example
>> the party group type. Is that what is intended? If so,
>> why?
>>
>>>> -David
>>>>
>>>>
>>>> -----Original Message-----
>>>>  >From: "Charles Johnson"<cj at
>>
>>
>> cehjohnson.uklinux.net>
>>
>>>>  >Sent: 1/22/06 4:29:45 AM
>>>>  >To: "OFBiz Users / Usage Discussion"<users at
>>
>>
>> lists.ofbiz.org>
>>
>>>>  >Subject: Re: [OFBiz] Users - Party and
>>
>>
>> Timezones
>>
>>>>  >
>>>>  >What about joining Person to timezone?
>>>>  >
>>>>  >CJ
>>>>  >
>>>>  >David E. Jones wrote:
>>>>  >
>>>>  >>
>>>>  >> No, I think Party would actually be better
>>
>>
>> than UserLogin. From a
>>
>>>>  >> modeling perspective and considering the
>>
>>
>> intent of the different
>>
>>>>  >> entities UserLogin doesn't make much sense,
>>
>>
>> unless I really mis-
>>
>>>>  >> understand what you intend to use this for
>>
>>
>> and what it would mean.
>>
>>>>  >> The UserLogin entity is part of the security
>>
>>
>> data model and the only
>>
>>>>  >> reasons a Party would have multiple UserLogin
>>
>>
>> records would be for
>>
>>>>  >> different permission sets or to change the
>>
>>
>> UserLogin but still
>>
>>>>  >> reserve the old one for tracking/auditing
>>
>>
>> purposes and such.
>>
>>>>  >>
>>>>  >> -David
>>>>  >>
>>>>  >>
>>>>  >> On Jan 21, 2006, at 6:09 PM, Vinay Agarwal
>>
>>
>> wrote:
>>
>>>>  >>
>>>>  >>> On second thought, it may be better to
>>
>>
>> associate timezone with a
>>
>>>>  >>> UserLogin
>>>>  >>> considering a party may have users in
>>
>>
>> different locations. This of
>>
>>>>  >>> course,
>>>>  >>> assumes that a single login is used by a
>>
>>
>> single user who would have a
>>
>>>>  >>> preferred timezone. Would this be better
>>
>>
>> than assigning it to a party?
>>
>>>>  >>>
>>>>  >>> Regards,
>>>>  >>> Vinay Agarwal
>>>>  >>>
>>>>  >>> -----Original Message-----
>>>>  >>> From: users-bounces at lists.ofbiz.org
>>
>>
>> [mailto:users-
>>
>>>>  >>> bounces at lists.ofbiz.org]
>>>>  >>> On Behalf Of David E. Jones
>>>>  >>> Sent: Friday, January 20, 2006 7:11 PM
>>>>  >>> To: OFBiz Users / Usage Discussion
>>>>  >>> Subject: Re: [OFBiz] Users - Party and
>>
>>
>> Timezones
>>
>>>>  >>>
>>>>  >>>
>>>>  >>> This is a tricky one since it may be correct
>>
>>
>> to say that a given
>>
>>>>  >>> Party corresponds to a single time zone. On
>>
>>
>> the other hand, I guess
>>
>>>>  >>> it depends on what you want to do with it...
>>
>>
>> it may be that having
>>
>>>>  >>> more than one time zone would mess up what
>>
>>
>> you are trying to do. In
>>
>>>>  >>> general the time zone probably goes along
>>
>>
>> best with the Postal
>>
>>>>  >>> Address, or perhaps even the Telecom Number.
>>
>>
>> If you need a single
>>
>>>>  >>> field, or call it a "preferredTimeZone" or
>>
>>
>> something along those
>>
>>>>  >>> lines to make it clear that it isn't
>>
>>
>> supposed to be the only one,
>>
>>>>  >>> then putting it right on the Party entity is
>>
>>
>> not a bad way to go.
>>
>>>>  >>>
>>>>  >>> -David
>>>>  >>>
>>>>  >>>
>>>>  >>> On Jan 20, 2006, at 1:44 PM, Vinay Agarwal
>>
>>
>> wrote:
>>
>>>>  >>>
>>>>  >>>> Hello,
>>>>  >>>>
>>>>  >>>> My application needs timezone setting for
>>
>>
>> each party. I haven't
>>
>>>>  >>>> been able to
>>>>  >>>> find any timezone setting for the party--is
>>
>>
>> there one? If not,
>>
>>>>  >>>> what's the
>>>>  >>>> preferred way for adding it? I assume
>>
>>
>> modifying the party entity is
>>
>>>>  >>>> NOT the
>>>>  >>>> preferred way. Any suggestions?
>>>>  >>>>
>>>>  >>>> Regards,
>>>>  >>>> Vinay Agarwal

Re: [OFBiz] Users - Party and Timezones

Posted by Adrian Crum <ad...@hlmksw.com>.
David,

Thanks for the reply!

Actually, I solved the problem by taking a different approach - I created a toTimeZone method that 
takes a String time zone ID and I put it in UtilDateTime. So, I can achieve the same result with

TimeZone userTz = UtilDateTime.toTimeZone(userLogin.getString("lastTimeZone"));



David E Jones wrote:

> 
> 
> Adrian Crum wrote:
> 
>> I'm going to include a small helper method that takes a UserLogin 
>> GenericValue and returns a TimeZone object. I don't know where to put 
>> it. UtilDateTime.java seems like a good choice, but it is a part of 
>> the base component, so I'm not sure if it should depend on the entity 
>> component. I looked around in the common component but I didn't see an 
>> appropriate home there.
> 
> 
> Checkout the UtilHttp.getCurrencyUom method. It gets the GenericValue 
> from the session, but just treats it as a Map to avoid a compile time 
> dependency on the entity component.
> 
> These little utility methods should probably just go into the UtilHttp 
> ones, along with the currency and locale methods.
> 
> 
> -David
> 

Re: [OFBiz] Users - Party and Timezones

Posted by David E Jones <jo...@hotwaxmedia.com>.

Adrian Crum wrote:
> I'm going to include a small helper method that takes a UserLogin 
> GenericValue and returns a TimeZone object. I don't know where to put 
> it. UtilDateTime.java seems like a good choice, but it is a part of the 
> base component, so I'm not sure if it should depend on the entity 
> component. I looked around in the common component but I didn't see an 
> appropriate home there.

Checkout the UtilHttp.getCurrencyUom method. It gets the GenericValue from the session, but just treats it as a Map to avoid a compile time dependency on the entity component.

These little utility methods should probably just go into the UtilHttp ones, along with the currency and locale methods.


-David

Re: [OFBiz] Users - Party and Timezones

Posted by Adrian Crum <ad...@hlmksw.com>.
I'm almost finished with the time zone selection modification and I have a question.

I'm going to include a small helper method that takes a UserLogin GenericValue and returns a 
TimeZone object. I don't know where to put it. UtilDateTime.java seems like a good choice, but it is 
a part of the base component, so I'm not sure if it should depend on the entity component. I looked 
around in the common component but I didn't see an appropriate home there.

Any suggestions?

-Adrian

Adrian Crum wrote:

> David,
> 
> Thank you very much for the reply! I will work on adding time zone 
> selection to the UserLogin entity. It shouldn't be too difficult - I can 
> just copy the existing locale selection logic and such.
> 
> Once that initial capability is committed to the project, I will begin 
> working on the Workeffort component calendar to make it more locale and 
> time zone aware.
> 
> -Adrian
> 
> David E Jones wrote:
> 
>>
>> You mention persisting settings in both the Party and UserLogin 
>> entities. On this I think it would be more consistent to just use the 
>> UserLogin entity as it has the lastLocale, etc and we could just add a 
>> lastTimeZone or the like.
>>
>> I agree it makes sense to be able to set and change this and use it 
>> for time entry and for calendar display.
>>
>> This looks like a bit of work... it's great that you're looking into 
>> it and please let everyone know if you run into any funny issues or 
>> need help with changing a bunch of stuff.
>>
>> -David
>>
>>
>> Adrian Crum wrote:
>>
>>> Okay, the UtilDateTime.java class has been updated to support locales 
>>> and time zones. That is the first step toward addressing the issue in 
>>> this thread.
>>>
>>> Now the question is, how and where do we persist the time zone? 
>>> Vinay's original question implied (and I may be wrong) that he needed 
>>> to assign time zones to parties. My use of time zones is more 
>>> user-oriented (for an online calendar program). This same type of use 
>>> can be found in the Workeffort calendar application.
>>>
>>> So, I see two uses for time zone info:
>>>   1. It can be persisted in the Party entity so that you can know the 
>>> time zone of another party.
>>>   2. An OFBiz user can select a time zone to control the display of 
>>> calendar data.
>>>
>>> Example: I log into OFBiz and set my time zone to control the display 
>>> of calendar data (#2). I check my calendar and see a reminder to call 
>>> a customer. Then I look in the customer's file to see what time zone 
>>> they are in so I will know the best time to call (#1).
>>>
>>> Jira issue OFBIZ-2 (https://issues.apache.org/jira/browse/OFBIZ-2) 
>>> contains a partially-completed implementation of #1.
>>>
>>> For #2 I was thinking of adding a time zone drop-down list under the 
>>> current locale drop-down list. Clicking the existing Set button would 
>>> update the user's locale AND time zone. The user's current time zone 
>>> selection would be handled in the same way as their locale: it would 
>>> be persisted in the UserLogin entity, and it can be retrieved via the 
>>> session attributes.
>>>
>>> What do you think?
>>>
>>> -Adrian
>>>
>>> Adrian Crum wrote:
>>>
>>>> I'm resurrecting this discussion because I have run into this issue 
>>>> also and I think it needs to be discussed again.
>>>>
>>>> To recap: OFBiz defaults to the timezone and locale of the server 
>>>> when handling dates and times. This can be a problem if a user is 
>>>> accessing OFBiz from outside the server's timezone/locale.
>>>>
>>>> What I've learned so far: java.util.Date stores the date/time as 
>>>> milliseconds since Jan 1, 1970. The date referenced is UTC. How the 
>>>> date/time is presented to the user depends upon the timezone and 
>>>> locale being used in Java code.
>>>>
>>>> OFBiz's UtilDateTime class uses the Java Date and Calendar classes 
>>>> without regard to a user's timezone or locale. UtilDateTime simply 
>>>> uses the server's locale and timezone. Java's Calendar class is able 
>>>> to convert the date and time correctly if it is initialized with the 
>>>> correct timezone and locale.
>>>>
>>>> I haven't researched how the various libraries OFBiz uses handle 
>>>> this issue.
>>>>
>>>> There is an outstanding Jira issue that addresses this: 
>>>> https://issues.apache.org/jira/browse/OFBIZ-2. Thanks to Jacques for 
>>>> pointing that out.
>>>>
>>>> I duplicated that work in my local copy because I didn't know 
>>>> someone had already done it. I ended up copying UtilDateTime to a 
>>>> new class and I re-wrote it to solve this problem. I'm in the 
>>>> process of using it now. Now that I'm aware of Vinay's patch, I'll 
>>>> probably use it instead.
>>>>
>>>> Implementing this change in the main project raises many issues and 
>>>> potential pitfalls - particularly with backward compatibility and 
>>>> legacy code.
>>>>
>>>> So, there is a solution to the problem, but I don't know how we can 
>>>> get it into the project.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> Chris Howe wrote:
>>>>
>>>>> I think this does bring up two issues.  The first
>>>>> being that the server should be storing and
>>>>> determining times in UTC, while displaying them in the
>>>>> local time of the client browser.  I know there are
>>>>> scripts available to do this through javascript.  The
>>>>> second issue is making more use of the
>>>>> WebUserPreference Entity.  I don't believe the
>>>>> WebUserPreference is currently being used for anything
>>>>> or has been developed into anything yet.  There is a
>>>>> slight issue with it's primary key as using
>>>>> UserLoginId, partyId, and webPreferenceTypeId is the
>>>>> same as using UserLoginId and webPreferenceTypeId
>>>>> since multiple partyIds cannot have the same
>>>>> UserLoginId.  This entity would also require a value
>>>>> field to be of any use in settings.  The only reason
>>>>> why I bring up the issue of webUserPreference is that
>>>>> you could store a userPreference override of detecting
>>>>> the local browser time.  Not to mention development
>>>>> would help bolster use in things like userLogin css
>>>>> overrides.  But again, it requires a value field to be
>>>>> of any use.
>>>>>
>>>>> ===============David Kunkel wrote:
>>>>>
>>>>> CJ
>>>>>
>>>>> I'm guessing you mean for the time zone data to mostly
>>>>> to be used in
>>>>> scheduling... For example:
>>>>>
>>>>> Have a local representation of the time the company
>>>>> planned the video
>>>>> conference.
>>>>>
>>>>> See the local time that an e-mail arrived.
>>>>>
>>>>> Can you expand on any other uses you've considered?
>>>>>
>>>>> Is there any way this information could be
>>>>> automatically obtained from
>>>>> the browser during the session, rather than something
>>>>> that would require
>>>>> specifically setting. If so, would we really want it
>>>>> added to the
>>>>> datamodel?
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>
>>>>> On Sun, 2006-01-22 at 21:13 +0000, Charles Johnson
>>>>> wrote:
>>>>>
>>>>>> Perhaps i shouldn't have volunteered that suggestion
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> as i'm not very
>>>>>
>>>>>> familiar with the ER yet. The reason i made it is
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> that a Person can only
>>>>>
>>>>>> be unitary and other entities may span multiple time
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> zones.
>>>>>
>>>>>> CJ
>>>>>>
>>>>>> David E. Jones wrote:
>>>>>>
>>>>>>
>>>>>>> Why Person? This would imply that the timezone
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> doesn't apply to other types of parties, for example
>>>>> the party group type. Is that what is intended? If so,
>>>>> why?
>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>>  >From: "Charles Johnson"<cj at
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> cehjohnson.uklinux.net>
>>>>>
>>>>>>>  >Sent: 1/22/06 4:29:45 AM
>>>>>>>  >To: "OFBiz Users / Usage Discussion"<users at
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> lists.ofbiz.org>
>>>>>
>>>>>>>  >Subject: Re: [OFBiz] Users - Party and
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Timezones
>>>>>
>>>>>>>  >
>>>>>>>  >What about joining Person to timezone?
>>>>>>>  >
>>>>>>>  >CJ
>>>>>>>  >
>>>>>>>  >David E. Jones wrote:
>>>>>>>  >
>>>>>>>  >>
>>>>>>>  >> No, I think Party would actually be better
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> than UserLogin. From a
>>>>>
>>>>>>>  >> modeling perspective and considering the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> intent of the different
>>>>>
>>>>>>>  >> entities UserLogin doesn't make much sense,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> unless I really mis-
>>>>>
>>>>>>>  >> understand what you intend to use this for
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> and what it would mean.
>>>>>
>>>>>>>  >> The UserLogin entity is part of the security
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> data model and the only
>>>>>
>>>>>>>  >> reasons a Party would have multiple UserLogin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> records would be for
>>>>>
>>>>>>>  >> different permission sets or to change the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> UserLogin but still
>>>>>
>>>>>>>  >> reserve the old one for tracking/auditing
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> purposes and such.
>>>>>
>>>>>>>  >>
>>>>>>>  >> -David
>>>>>>>  >>
>>>>>>>  >>
>>>>>>>  >> On Jan 21, 2006, at 6:09 PM, Vinay Agarwal
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> wrote:
>>>>>
>>>>>>>  >>
>>>>>>>  >>> On second thought, it may be better to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> associate timezone with a
>>>>>
>>>>>>>  >>> UserLogin
>>>>>>>  >>> considering a party may have users in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> different locations. This of
>>>>>
>>>>>>>  >>> course,
>>>>>>>  >>> assumes that a single login is used by a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> single user who would have a
>>>>>
>>>>>>>  >>> preferred timezone. Would this be better
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> than assigning it to a party?
>>>>>
>>>>>>>  >>>
>>>>>>>  >>> Regards,
>>>>>>>  >>> Vinay Agarwal
>>>>>>>  >>>
>>>>>>>  >>> -----Original Message-----
>>>>>>>  >>> From: users-bounces at lists.ofbiz.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> [mailto:users-
>>>>>
>>>>>>>  >>> bounces at lists.ofbiz.org]
>>>>>>>  >>> On Behalf Of David E. Jones
>>>>>>>  >>> Sent: Friday, January 20, 2006 7:11 PM
>>>>>>>  >>> To: OFBiz Users / Usage Discussion
>>>>>>>  >>> Subject: Re: [OFBiz] Users - Party and
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Timezones
>>>>>
>>>>>>>  >>>
>>>>>>>  >>>
>>>>>>>  >>> This is a tricky one since it may be correct
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> to say that a given
>>>>>
>>>>>>>  >>> Party corresponds to a single time zone. On
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> the other hand, I guess
>>>>>
>>>>>>>  >>> it depends on what you want to do with it...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> it may be that having
>>>>>
>>>>>>>  >>> more than one time zone would mess up what
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> you are trying to do. In
>>>>>
>>>>>>>  >>> general the time zone probably goes along
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> best with the Postal
>>>>>
>>>>>>>  >>> Address, or perhaps even the Telecom Number.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> If you need a single
>>>>>
>>>>>>>  >>> field, or call it a "preferredTimeZone" or
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> something along those
>>>>>
>>>>>>>  >>> lines to make it clear that it isn't
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> supposed to be the only one,
>>>>>
>>>>>>>  >>> then putting it right on the Party entity is
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> not a bad way to go.
>>>>>
>>>>>>>  >>>
>>>>>>>  >>> -David
>>>>>>>  >>>
>>>>>>>  >>>
>>>>>>>  >>> On Jan 20, 2006, at 1:44 PM, Vinay Agarwal
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> wrote:
>>>>>
>>>>>>>  >>>
>>>>>>>  >>>> Hello,
>>>>>>>  >>>>
>>>>>>>  >>>> My application needs timezone setting for
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> each party. I haven't
>>>>>
>>>>>>>  >>>> been able to
>>>>>>>  >>>> find any timezone setting for the party--is
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> there one? If not,
>>>>>
>>>>>>>  >>>> what's the
>>>>>>>  >>>> preferred way for adding it? I assume
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> modifying the party entity is
>>>>>
>>>>>>>  >>>> NOT the
>>>>>>>  >>>> preferred way. Any suggestions?
>>>>>>>  >>>>
>>>>>>>  >>>> Regards,
>>>>>>>  >>>> Vinay Agarwal
>>
>>
>>
> 

Re: [OFBiz] Users - Party and Timezones

Posted by Adrian Crum <ad...@hlmksw.com>.
David,

Thank you very much for the reply! I will work on adding time zone selection to the UserLogin 
entity. It shouldn't be too difficult - I can just copy the existing locale selection logic and such.

Once that initial capability is committed to the project, I will begin working on the Workeffort 
component calendar to make it more locale and time zone aware.

-Adrian

David E Jones wrote:
> 
> You mention persisting settings in both the Party and UserLogin 
> entities. On this I think it would be more consistent to just use the 
> UserLogin entity as it has the lastLocale, etc and we could just add a 
> lastTimeZone or the like.
> 
> I agree it makes sense to be able to set and change this and use it for 
> time entry and for calendar display.
> 
> This looks like a bit of work... it's great that you're looking into it 
> and please let everyone know if you run into any funny issues or need 
> help with changing a bunch of stuff.
> 
> -David
> 
> 
> Adrian Crum wrote:
> 
>> Okay, the UtilDateTime.java class has been updated to support locales 
>> and time zones. That is the first step toward addressing the issue in 
>> this thread.
>>
>> Now the question is, how and where do we persist the time zone? 
>> Vinay's original question implied (and I may be wrong) that he needed 
>> to assign time zones to parties. My use of time zones is more 
>> user-oriented (for an online calendar program). This same type of use 
>> can be found in the Workeffort calendar application.
>>
>> So, I see two uses for time zone info:
>>   1. It can be persisted in the Party entity so that you can know the 
>> time zone of another party.
>>   2. An OFBiz user can select a time zone to control the display of 
>> calendar data.
>>
>> Example: I log into OFBiz and set my time zone to control the display 
>> of calendar data (#2). I check my calendar and see a reminder to call 
>> a customer. Then I look in the customer's file to see what time zone 
>> they are in so I will know the best time to call (#1).
>>
>> Jira issue OFBIZ-2 (https://issues.apache.org/jira/browse/OFBIZ-2) 
>> contains a partially-completed implementation of #1.
>>
>> For #2 I was thinking of adding a time zone drop-down list under the 
>> current locale drop-down list. Clicking the existing Set button would 
>> update the user's locale AND time zone. The user's current time zone 
>> selection would be handled in the same way as their locale: it would 
>> be persisted in the UserLogin entity, and it can be retrieved via the 
>> session attributes.
>>
>> What do you think?
>>
>> -Adrian
>>
>> Adrian Crum wrote:
>>
>>> I'm resurrecting this discussion because I have run into this issue 
>>> also and I think it needs to be discussed again.
>>>
>>> To recap: OFBiz defaults to the timezone and locale of the server 
>>> when handling dates and times. This can be a problem if a user is 
>>> accessing OFBiz from outside the server's timezone/locale.
>>>
>>> What I've learned so far: java.util.Date stores the date/time as 
>>> milliseconds since Jan 1, 1970. The date referenced is UTC. How the 
>>> date/time is presented to the user depends upon the timezone and 
>>> locale being used in Java code.
>>>
>>> OFBiz's UtilDateTime class uses the Java Date and Calendar classes 
>>> without regard to a user's timezone or locale. UtilDateTime simply 
>>> uses the server's locale and timezone. Java's Calendar class is able 
>>> to convert the date and time correctly if it is initialized with the 
>>> correct timezone and locale.
>>>
>>> I haven't researched how the various libraries OFBiz uses handle this 
>>> issue.
>>>
>>> There is an outstanding Jira issue that addresses this: 
>>> https://issues.apache.org/jira/browse/OFBIZ-2. Thanks to Jacques for 
>>> pointing that out.
>>>
>>> I duplicated that work in my local copy because I didn't know someone 
>>> had already done it. I ended up copying UtilDateTime to a new class 
>>> and I re-wrote it to solve this problem. I'm in the process of using 
>>> it now. Now that I'm aware of Vinay's patch, I'll probably use it 
>>> instead.
>>>
>>> Implementing this change in the main project raises many issues and 
>>> potential pitfalls - particularly with backward compatibility and 
>>> legacy code.
>>>
>>> So, there is a solution to the problem, but I don't know how we can 
>>> get it into the project.
>>>
>>> -Adrian
>>>
>>>
>>> Chris Howe wrote:
>>>
>>>> I think this does bring up two issues.  The first
>>>> being that the server should be storing and
>>>> determining times in UTC, while displaying them in the
>>>> local time of the client browser.  I know there are
>>>> scripts available to do this through javascript.  The
>>>> second issue is making more use of the
>>>> WebUserPreference Entity.  I don't believe the
>>>> WebUserPreference is currently being used for anything
>>>> or has been developed into anything yet.  There is a
>>>> slight issue with it's primary key as using
>>>> UserLoginId, partyId, and webPreferenceTypeId is the
>>>> same as using UserLoginId and webPreferenceTypeId
>>>> since multiple partyIds cannot have the same
>>>> UserLoginId.  This entity would also require a value
>>>> field to be of any use in settings.  The only reason
>>>> why I bring up the issue of webUserPreference is that
>>>> you could store a userPreference override of detecting
>>>> the local browser time.  Not to mention development
>>>> would help bolster use in things like userLogin css
>>>> overrides.  But again, it requires a value field to be
>>>> of any use.
>>>>
>>>> ===============David Kunkel wrote:
>>>>
>>>> CJ
>>>>
>>>> I'm guessing you mean for the time zone data to mostly
>>>> to be used in
>>>> scheduling... For example:
>>>>
>>>> Have a local representation of the time the company
>>>> planned the video
>>>> conference.
>>>>
>>>> See the local time that an e-mail arrived.
>>>>
>>>> Can you expand on any other uses you've considered?
>>>>
>>>> Is there any way this information could be
>>>> automatically obtained from
>>>> the browser during the session, rather than something
>>>> that would require
>>>> specifically setting. If so, would we really want it
>>>> added to the
>>>> datamodel?
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>> On Sun, 2006-01-22 at 21:13 +0000, Charles Johnson
>>>> wrote:
>>>>
>>>>> Perhaps i shouldn't have volunteered that suggestion
>>>>
>>>>
>>>>
>>>> as i'm not very
>>>>
>>>>> familiar with the ER yet. The reason i made it is
>>>>
>>>>
>>>>
>>>> that a Person can only
>>>>
>>>>> be unitary and other entities may span multiple time
>>>>
>>>>
>>>>
>>>> zones.
>>>>
>>>>> CJ
>>>>>
>>>>> David E. Jones wrote:
>>>>>
>>>>>
>>>>>> Why Person? This would imply that the timezone
>>>>
>>>>
>>>>
>>>> doesn't apply to other types of parties, for example
>>>> the party group type. Is that what is intended? If so,
>>>> why?
>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>>  >From: "Charles Johnson"<cj at
>>>>
>>>>
>>>>
>>>> cehjohnson.uklinux.net>
>>>>
>>>>>>  >Sent: 1/22/06 4:29:45 AM
>>>>>>  >To: "OFBiz Users / Usage Discussion"<users at
>>>>
>>>>
>>>>
>>>> lists.ofbiz.org>
>>>>
>>>>>>  >Subject: Re: [OFBiz] Users - Party and
>>>>
>>>>
>>>>
>>>> Timezones
>>>>
>>>>>>  >
>>>>>>  >What about joining Person to timezone?
>>>>>>  >
>>>>>>  >CJ
>>>>>>  >
>>>>>>  >David E. Jones wrote:
>>>>>>  >
>>>>>>  >>
>>>>>>  >> No, I think Party would actually be better
>>>>
>>>>
>>>>
>>>> than UserLogin. From a
>>>>
>>>>>>  >> modeling perspective and considering the
>>>>
>>>>
>>>>
>>>> intent of the different
>>>>
>>>>>>  >> entities UserLogin doesn't make much sense,
>>>>
>>>>
>>>>
>>>> unless I really mis-
>>>>
>>>>>>  >> understand what you intend to use this for
>>>>
>>>>
>>>>
>>>> and what it would mean.
>>>>
>>>>>>  >> The UserLogin entity is part of the security
>>>>
>>>>
>>>>
>>>> data model and the only
>>>>
>>>>>>  >> reasons a Party would have multiple UserLogin
>>>>
>>>>
>>>>
>>>> records would be for
>>>>
>>>>>>  >> different permission sets or to change the
>>>>
>>>>
>>>>
>>>> UserLogin but still
>>>>
>>>>>>  >> reserve the old one for tracking/auditing
>>>>
>>>>
>>>>
>>>> purposes and such.
>>>>
>>>>>>  >>
>>>>>>  >> -David
>>>>>>  >>
>>>>>>  >>
>>>>>>  >> On Jan 21, 2006, at 6:09 PM, Vinay Agarwal
>>>>
>>>>
>>>>
>>>> wrote:
>>>>
>>>>>>  >>
>>>>>>  >>> On second thought, it may be better to
>>>>
>>>>
>>>>
>>>> associate timezone with a
>>>>
>>>>>>  >>> UserLogin
>>>>>>  >>> considering a party may have users in
>>>>
>>>>
>>>>
>>>> different locations. This of
>>>>
>>>>>>  >>> course,
>>>>>>  >>> assumes that a single login is used by a
>>>>
>>>>
>>>>
>>>> single user who would have a
>>>>
>>>>>>  >>> preferred timezone. Would this be better
>>>>
>>>>
>>>>
>>>> than assigning it to a party?
>>>>
>>>>>>  >>>
>>>>>>  >>> Regards,
>>>>>>  >>> Vinay Agarwal
>>>>>>  >>>
>>>>>>  >>> -----Original Message-----
>>>>>>  >>> From: users-bounces at lists.ofbiz.org
>>>>
>>>>
>>>>
>>>> [mailto:users-
>>>>
>>>>>>  >>> bounces at lists.ofbiz.org]
>>>>>>  >>> On Behalf Of David E. Jones
>>>>>>  >>> Sent: Friday, January 20, 2006 7:11 PM
>>>>>>  >>> To: OFBiz Users / Usage Discussion
>>>>>>  >>> Subject: Re: [OFBiz] Users - Party and
>>>>
>>>>
>>>>
>>>> Timezones
>>>>
>>>>>>  >>>
>>>>>>  >>>
>>>>>>  >>> This is a tricky one since it may be correct
>>>>
>>>>
>>>>
>>>> to say that a given
>>>>
>>>>>>  >>> Party corresponds to a single time zone. On
>>>>
>>>>
>>>>
>>>> the other hand, I guess
>>>>
>>>>>>  >>> it depends on what you want to do with it...
>>>>
>>>>
>>>>
>>>> it may be that having
>>>>
>>>>>>  >>> more than one time zone would mess up what
>>>>
>>>>
>>>>
>>>> you are trying to do. In
>>>>
>>>>>>  >>> general the time zone probably goes along
>>>>
>>>>
>>>>
>>>> best with the Postal
>>>>
>>>>>>  >>> Address, or perhaps even the Telecom Number.
>>>>
>>>>
>>>>
>>>> If you need a single
>>>>
>>>>>>  >>> field, or call it a "preferredTimeZone" or
>>>>
>>>>
>>>>
>>>> something along those
>>>>
>>>>>>  >>> lines to make it clear that it isn't
>>>>
>>>>
>>>>
>>>> supposed to be the only one,
>>>>
>>>>>>  >>> then putting it right on the Party entity is
>>>>
>>>>
>>>>
>>>> not a bad way to go.
>>>>
>>>>>>  >>>
>>>>>>  >>> -David
>>>>>>  >>>
>>>>>>  >>>
>>>>>>  >>> On Jan 20, 2006, at 1:44 PM, Vinay Agarwal
>>>>
>>>>
>>>>
>>>> wrote:
>>>>
>>>>>>  >>>
>>>>>>  >>>> Hello,
>>>>>>  >>>>
>>>>>>  >>>> My application needs timezone setting for
>>>>
>>>>
>>>>
>>>> each party. I haven't
>>>>
>>>>>>  >>>> been able to
>>>>>>  >>>> find any timezone setting for the party--is
>>>>
>>>>
>>>>
>>>> there one? If not,
>>>>
>>>>>>  >>>> what's the
>>>>>>  >>>> preferred way for adding it? I assume
>>>>
>>>>
>>>>
>>>> modifying the party entity is
>>>>
>>>>>>  >>>> NOT the
>>>>>>  >>>> preferred way. Any suggestions?
>>>>>>  >>>>
>>>>>>  >>>> Regards,
>>>>>>  >>>> Vinay Agarwal
> 
> 

Re: [OFBiz] Users - Party and Timezones

Posted by Adrian Crum <ad...@hlmksw.com>.
Okay, the initial work is done. Here is where I could use some help. Could someone review/commit 
OFBIZ-1079? (https://issues.apache.org/jira/browse/OFBIZ-1079)


David E Jones wrote:

> 
> You mention persisting settings in both the Party and UserLogin 
> entities. On this I think it would be more consistent to just use the 
> UserLogin entity as it has the lastLocale, etc and we could just add a 
> lastTimeZone or the like.
> 
> I agree it makes sense to be able to set and change this and use it for 
> time entry and for calendar display.
> 
> This looks like a bit of work... it's great that you're looking into it 
> and please let everyone know if you run into any funny issues or need 
> help with changing a bunch of stuff.
> 
> -David
> 
> 
> Adrian Crum wrote:
> 
>> Okay, the UtilDateTime.java class has been updated to support locales 
>> and time zones. That is the first step toward addressing the issue in 
>> this thread.
>>
>> Now the question is, how and where do we persist the time zone? 
>> Vinay's original question implied (and I may be wrong) that he needed 
>> to assign time zones to parties. My use of time zones is more 
>> user-oriented (for an online calendar program). This same type of use 
>> can be found in the Workeffort calendar application.
>>
>> So, I see two uses for time zone info:
>>   1. It can be persisted in the Party entity so that you can know the 
>> time zone of another party.
>>   2. An OFBiz user can select a time zone to control the display of 
>> calendar data.
>>
>> Example: I log into OFBiz and set my time zone to control the display 
>> of calendar data (#2). I check my calendar and see a reminder to call 
>> a customer. Then I look in the customer's file to see what time zone 
>> they are in so I will know the best time to call (#1).
>>
>> Jira issue OFBIZ-2 (https://issues.apache.org/jira/browse/OFBIZ-2) 
>> contains a partially-completed implementation of #1.
>>
>> For #2 I was thinking of adding a time zone drop-down list under the 
>> current locale drop-down list. Clicking the existing Set button would 
>> update the user's locale AND time zone. The user's current time zone 
>> selection would be handled in the same way as their locale: it would 
>> be persisted in the UserLogin entity, and it can be retrieved via the 
>> session attributes.
>>
>> What do you think?
>>
>> -Adrian
>>
>> Adrian Crum wrote:
>>
>>> I'm resurrecting this discussion because I have run into this issue 
>>> also and I think it needs to be discussed again.
>>>
>>> To recap: OFBiz defaults to the timezone and locale of the server 
>>> when handling dates and times. This can be a problem if a user is 
>>> accessing OFBiz from outside the server's timezone/locale.
>>>
>>> What I've learned so far: java.util.Date stores the date/time as 
>>> milliseconds since Jan 1, 1970. The date referenced is UTC. How the 
>>> date/time is presented to the user depends upon the timezone and 
>>> locale being used in Java code.
>>>
>>> OFBiz's UtilDateTime class uses the Java Date and Calendar classes 
>>> without regard to a user's timezone or locale. UtilDateTime simply 
>>> uses the server's locale and timezone. Java's Calendar class is able 
>>> to convert the date and time correctly if it is initialized with the 
>>> correct timezone and locale.
>>>
>>> I haven't researched how the various libraries OFBiz uses handle this 
>>> issue.
>>>
>>> There is an outstanding Jira issue that addresses this: 
>>> https://issues.apache.org/jira/browse/OFBIZ-2. Thanks to Jacques for 
>>> pointing that out.
>>>
>>> I duplicated that work in my local copy because I didn't know someone 
>>> had already done it. I ended up copying UtilDateTime to a new class 
>>> and I re-wrote it to solve this problem. I'm in the process of using 
>>> it now. Now that I'm aware of Vinay's patch, I'll probably use it 
>>> instead.
>>>
>>> Implementing this change in the main project raises many issues and 
>>> potential pitfalls - particularly with backward compatibility and 
>>> legacy code.
>>>
>>> So, there is a solution to the problem, but I don't know how we can 
>>> get it into the project.
>>>
>>> -Adrian
>>>
>>>
>>> Chris Howe wrote:
>>>
>>>> I think this does bring up two issues.  The first
>>>> being that the server should be storing and
>>>> determining times in UTC, while displaying them in the
>>>> local time of the client browser.  I know there are
>>>> scripts available to do this through javascript.  The
>>>> second issue is making more use of the
>>>> WebUserPreference Entity.  I don't believe the
>>>> WebUserPreference is currently being used for anything
>>>> or has been developed into anything yet.  There is a
>>>> slight issue with it's primary key as using
>>>> UserLoginId, partyId, and webPreferenceTypeId is the
>>>> same as using UserLoginId and webPreferenceTypeId
>>>> since multiple partyIds cannot have the same
>>>> UserLoginId.  This entity would also require a value
>>>> field to be of any use in settings.  The only reason
>>>> why I bring up the issue of webUserPreference is that
>>>> you could store a userPreference override of detecting
>>>> the local browser time.  Not to mention development
>>>> would help bolster use in things like userLogin css
>>>> overrides.  But again, it requires a value field to be
>>>> of any use.
>>>>
>>>> ===============David Kunkel wrote:
>>>>
>>>> CJ
>>>>
>>>> I'm guessing you mean for the time zone data to mostly
>>>> to be used in
>>>> scheduling... For example:
>>>>
>>>> Have a local representation of the time the company
>>>> planned the video
>>>> conference.
>>>>
>>>> See the local time that an e-mail arrived.
>>>>
>>>> Can you expand on any other uses you've considered?
>>>>
>>>> Is there any way this information could be
>>>> automatically obtained from
>>>> the browser during the session, rather than something
>>>> that would require
>>>> specifically setting. If so, would we really want it
>>>> added to the
>>>> datamodel?
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>> On Sun, 2006-01-22 at 21:13 +0000, Charles Johnson
>>>> wrote:
>>>>
>>>>> Perhaps i shouldn't have volunteered that suggestion
>>>>
>>>>
>>>>
>>>> as i'm not very
>>>>
>>>>> familiar with the ER yet. The reason i made it is
>>>>
>>>>
>>>>
>>>> that a Person can only
>>>>
>>>>> be unitary and other entities may span multiple time
>>>>
>>>>
>>>>
>>>> zones.
>>>>
>>>>> CJ
>>>>>
>>>>> David E. Jones wrote:
>>>>>
>>>>>
>>>>>> Why Person? This would imply that the timezone
>>>>
>>>>
>>>>
>>>> doesn't apply to other types of parties, for example
>>>> the party group type. Is that what is intended? If so,
>>>> why?
>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>>  >From: "Charles Johnson"<cj at
>>>>
>>>>
>>>>
>>>> cehjohnson.uklinux.net>
>>>>
>>>>>>  >Sent: 1/22/06 4:29:45 AM
>>>>>>  >To: "OFBiz Users / Usage Discussion"<users at
>>>>
>>>>
>>>>
>>>> lists.ofbiz.org>
>>>>
>>>>>>  >Subject: Re: [OFBiz] Users - Party and
>>>>
>>>>
>>>>
>>>> Timezones
>>>>
>>>>>>  >
>>>>>>  >What about joining Person to timezone?
>>>>>>  >
>>>>>>  >CJ
>>>>>>  >
>>>>>>  >David E. Jones wrote:
>>>>>>  >
>>>>>>  >>
>>>>>>  >> No, I think Party would actually be better
>>>>
>>>>
>>>>
>>>> than UserLogin. From a
>>>>
>>>>>>  >> modeling perspective and considering the
>>>>
>>>>
>>>>
>>>> intent of the different
>>>>
>>>>>>  >> entities UserLogin doesn't make much sense,
>>>>
>>>>
>>>>
>>>> unless I really mis-
>>>>
>>>>>>  >> understand what you intend to use this for
>>>>
>>>>
>>>>
>>>> and what it would mean.
>>>>
>>>>>>  >> The UserLogin entity is part of the security
>>>>
>>>>
>>>>
>>>> data model and the only
>>>>
>>>>>>  >> reasons a Party would have multiple UserLogin
>>>>
>>>>
>>>>
>>>> records would be for
>>>>
>>>>>>  >> different permission sets or to change the
>>>>
>>>>
>>>>
>>>> UserLogin but still
>>>>
>>>>>>  >> reserve the old one for tracking/auditing
>>>>
>>>>
>>>>
>>>> purposes and such.
>>>>
>>>>>>  >>
>>>>>>  >> -David
>>>>>>  >>
>>>>>>  >>
>>>>>>  >> On Jan 21, 2006, at 6:09 PM, Vinay Agarwal
>>>>
>>>>
>>>>
>>>> wrote:
>>>>
>>>>>>  >>
>>>>>>  >>> On second thought, it may be better to
>>>>
>>>>
>>>>
>>>> associate timezone with a
>>>>
>>>>>>  >>> UserLogin
>>>>>>  >>> considering a party may have users in
>>>>
>>>>
>>>>
>>>> different locations. This of
>>>>
>>>>>>  >>> course,
>>>>>>  >>> assumes that a single login is used by a
>>>>
>>>>
>>>>
>>>> single user who would have a
>>>>
>>>>>>  >>> preferred timezone. Would this be better
>>>>
>>>>
>>>>
>>>> than assigning it to a party?
>>>>
>>>>>>  >>>
>>>>>>  >>> Regards,
>>>>>>  >>> Vinay Agarwal
>>>>>>  >>>
>>>>>>  >>> -----Original Message-----
>>>>>>  >>> From: users-bounces at lists.ofbiz.org
>>>>
>>>>
>>>>
>>>> [mailto:users-
>>>>
>>>>>>  >>> bounces at lists.ofbiz.org]
>>>>>>  >>> On Behalf Of David E. Jones
>>>>>>  >>> Sent: Friday, January 20, 2006 7:11 PM
>>>>>>  >>> To: OFBiz Users / Usage Discussion
>>>>>>  >>> Subject: Re: [OFBiz] Users - Party and
>>>>
>>>>
>>>>
>>>> Timezones
>>>>
>>>>>>  >>>
>>>>>>  >>>
>>>>>>  >>> This is a tricky one since it may be correct
>>>>
>>>>
>>>>
>>>> to say that a given
>>>>
>>>>>>  >>> Party corresponds to a single time zone. On
>>>>
>>>>
>>>>
>>>> the other hand, I guess
>>>>
>>>>>>  >>> it depends on what you want to do with it...
>>>>
>>>>
>>>>
>>>> it may be that having
>>>>
>>>>>>  >>> more than one time zone would mess up what
>>>>
>>>>
>>>>
>>>> you are trying to do. In
>>>>
>>>>>>  >>> general the time zone probably goes along
>>>>
>>>>
>>>>
>>>> best with the Postal
>>>>
>>>>>>  >>> Address, or perhaps even the Telecom Number.
>>>>
>>>>
>>>>
>>>> If you need a single
>>>>
>>>>>>  >>> field, or call it a "preferredTimeZone" or
>>>>
>>>>
>>>>
>>>> something along those
>>>>
>>>>>>  >>> lines to make it clear that it isn't
>>>>
>>>>
>>>>
>>>> supposed to be the only one,
>>>>
>>>>>>  >>> then putting it right on the Party entity is
>>>>
>>>>
>>>>
>>>> not a bad way to go.
>>>>
>>>>>>  >>>
>>>>>>  >>> -David
>>>>>>  >>>
>>>>>>  >>>
>>>>>>  >>> On Jan 20, 2006, at 1:44 PM, Vinay Agarwal
>>>>
>>>>
>>>>
>>>> wrote:
>>>>
>>>>>>  >>>
>>>>>>  >>>> Hello,
>>>>>>  >>>>
>>>>>>  >>>> My application needs timezone setting for
>>>>
>>>>
>>>>
>>>> each party. I haven't
>>>>
>>>>>>  >>>> been able to
>>>>>>  >>>> find any timezone setting for the party--is
>>>>
>>>>
>>>>
>>>> there one? If not,
>>>>
>>>>>>  >>>> what's the
>>>>>>  >>>> preferred way for adding it? I assume
>>>>
>>>>
>>>>
>>>> modifying the party entity is
>>>>
>>>>>>  >>>> NOT the
>>>>>>  >>>> preferred way. Any suggestions?
>>>>>>  >>>>
>>>>>>  >>>> Regards,
>>>>>>  >>>> Vinay Agarwal
> 
> 

Re: [OFBiz] Users - Party and Timezones

Posted by Daniel Martínez <da...@paradisosistemas.es>.
Just some ideas ...

I think it will be useful also to include the timezone in the party
entity. If a party(=customer) does not have any user associated (which
will be usual for non-ecommerce based companies) then we can't address
the use case Adrian describes. Even better will be to associate
timezones with GeoData.
--
Daniel

David E Jones escribió:
>
> You mention persisting settings in both the Party and UserLogin
> entities. On this I think it would be more consistent to just use the
> UserLogin entity as it has the lastLocale, etc and we could just add a
> lastTimeZone or the like.
>
> I agree it makes sense to be able to set and change this and use it
> for time entry and for calendar display.
>
> This looks like a bit of work... it's great that you're looking into
> it and please let everyone know if you run into any funny issues or
> need help with changing a bunch of stuff.
>
> -David
>
>
> Adrian Crum wrote:
>> Okay, the UtilDateTime.java class has been updated to support locales
>> and time zones. That is the first step toward addressing the issue in
>> this thread.
>>
>> Now the question is, how and where do we persist the time zone?
>> Vinay's original question implied (and I may be wrong) that he needed
>> to assign time zones to parties. My use of time zones is more
>> user-oriented (for an online calendar program). This same type of use
>> can be found in the Workeffort calendar application.
>>


Re: [OFBiz] Users - Party and Timezones

Posted by David E Jones <jo...@hotwaxmedia.com>.
You mention persisting settings in both the Party and UserLogin entities. On this I think it would be more consistent to just use the UserLogin entity as it has the lastLocale, etc and we could just add a lastTimeZone or the like.

I agree it makes sense to be able to set and change this and use it for time entry and for calendar display.

This looks like a bit of work... it's great that you're looking into it and please let everyone know if you run into any funny issues or need help with changing a bunch of stuff.

-David


Adrian Crum wrote:
> Okay, the UtilDateTime.java class has been updated to support locales 
> and time zones. That is the first step toward addressing the issue in 
> this thread.
> 
> Now the question is, how and where do we persist the time zone? Vinay's 
> original question implied (and I may be wrong) that he needed to assign 
> time zones to parties. My use of time zones is more user-oriented (for 
> an online calendar program). This same type of use can be found in the 
> Workeffort calendar application.
> 
> So, I see two uses for time zone info:
>   1. It can be persisted in the Party entity so that you can know the 
> time zone of another party.
>   2. An OFBiz user can select a time zone to control the display of 
> calendar data.
> 
> Example: I log into OFBiz and set my time zone to control the display of 
> calendar data (#2). I check my calendar and see a reminder to call a 
> customer. Then I look in the customer's file to see what time zone they 
> are in so I will know the best time to call (#1).
> 
> Jira issue OFBIZ-2 (https://issues.apache.org/jira/browse/OFBIZ-2) 
> contains a partially-completed implementation of #1.
> 
> For #2 I was thinking of adding a time zone drop-down list under the 
> current locale drop-down list. Clicking the existing Set button would 
> update the user's locale AND time zone. The user's current time zone 
> selection would be handled in the same way as their locale: it would be 
> persisted in the UserLogin entity, and it can be retrieved via the 
> session attributes.
> 
> What do you think?
> 
> -Adrian
> 
> Adrian Crum wrote:
>> I'm resurrecting this discussion because I have run into this issue 
>> also and I think it needs to be discussed again.
>>
>> To recap: OFBiz defaults to the timezone and locale of the server when 
>> handling dates and times. This can be a problem if a user is accessing 
>> OFBiz from outside the server's timezone/locale.
>>
>> What I've learned so far: java.util.Date stores the date/time as 
>> milliseconds since Jan 1, 1970. The date referenced is UTC. How the 
>> date/time is presented to the user depends upon the timezone and 
>> locale being used in Java code.
>>
>> OFBiz's UtilDateTime class uses the Java Date and Calendar classes 
>> without regard to a user's timezone or locale. UtilDateTime simply 
>> uses the server's locale and timezone. Java's Calendar class is able 
>> to convert the date and time correctly if it is initialized with the 
>> correct timezone and locale.
>>
>> I haven't researched how the various libraries OFBiz uses handle this 
>> issue.
>>
>> There is an outstanding Jira issue that addresses this: 
>> https://issues.apache.org/jira/browse/OFBIZ-2. Thanks to Jacques for 
>> pointing that out.
>>
>> I duplicated that work in my local copy because I didn't know someone 
>> had already done it. I ended up copying UtilDateTime to a new class 
>> and I re-wrote it to solve this problem. I'm in the process of using 
>> it now. Now that I'm aware of Vinay's patch, I'll probably use it 
>> instead.
>>
>> Implementing this change in the main project raises many issues and 
>> potential pitfalls - particularly with backward compatibility and 
>> legacy code.
>>
>> So, there is a solution to the problem, but I don't know how we can 
>> get it into the project.
>>
>> -Adrian
>>
>>
>> Chris Howe wrote:
>>
>>> I think this does bring up two issues.  The first
>>> being that the server should be storing and
>>> determining times in UTC, while displaying them in the
>>> local time of the client browser.  I know there are
>>> scripts available to do this through javascript.  The
>>> second issue is making more use of the
>>> WebUserPreference Entity.  I don't believe the
>>> WebUserPreference is currently being used for anything
>>> or has been developed into anything yet.  There is a
>>> slight issue with it's primary key as using
>>> UserLoginId, partyId, and webPreferenceTypeId is the
>>> same as using UserLoginId and webPreferenceTypeId
>>> since multiple partyIds cannot have the same
>>> UserLoginId.  This entity would also require a value
>>> field to be of any use in settings.  The only reason
>>> why I bring up the issue of webUserPreference is that
>>> you could store a userPreference override of detecting
>>> the local browser time.  Not to mention development
>>> would help bolster use in things like userLogin css
>>> overrides.  But again, it requires a value field to be
>>> of any use.
>>>
>>> ===============David Kunkel wrote:
>>>
>>> CJ
>>>
>>> I'm guessing you mean for the time zone data to mostly
>>> to be used in
>>> scheduling... For example:
>>>
>>> Have a local representation of the time the company
>>> planned the video
>>> conference.
>>>
>>> See the local time that an e-mail arrived.
>>>
>>> Can you expand on any other uses you've considered?
>>>
>>> Is there any way this information could be
>>> automatically obtained from
>>> the browser during the session, rather than something
>>> that would require
>>> specifically setting. If so, would we really want it
>>> added to the
>>> datamodel?
>>>
>>> Thanks
>>>
>>>
>>>
>>> On Sun, 2006-01-22 at 21:13 +0000, Charles Johnson
>>> wrote:
>>>
>>>> Perhaps i shouldn't have volunteered that suggestion
>>>
>>>
>>> as i'm not very
>>>
>>>> familiar with the ER yet. The reason i made it is
>>>
>>>
>>> that a Person can only
>>>
>>>> be unitary and other entities may span multiple time
>>>
>>>
>>> zones.
>>>
>>>> CJ
>>>>
>>>> David E. Jones wrote:
>>>>
>>>>
>>>>> Why Person? This would imply that the timezone
>>>
>>>
>>> doesn't apply to other types of parties, for example
>>> the party group type. Is that what is intended? If so,
>>> why?
>>>
>>>>> -David
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>>  >From: "Charles Johnson"<cj at
>>>
>>>
>>> cehjohnson.uklinux.net>
>>>
>>>>>  >Sent: 1/22/06 4:29:45 AM
>>>>>  >To: "OFBiz Users / Usage Discussion"<users at
>>>
>>>
>>> lists.ofbiz.org>
>>>
>>>>>  >Subject: Re: [OFBiz] Users - Party and
>>>
>>>
>>> Timezones
>>>
>>>>>  >
>>>>>  >What about joining Person to timezone?
>>>>>  >
>>>>>  >CJ
>>>>>  >
>>>>>  >David E. Jones wrote:
>>>>>  >
>>>>>  >>
>>>>>  >> No, I think Party would actually be better
>>>
>>>
>>> than UserLogin. From a
>>>
>>>>>  >> modeling perspective and considering the
>>>
>>>
>>> intent of the different
>>>
>>>>>  >> entities UserLogin doesn't make much sense,
>>>
>>>
>>> unless I really mis-
>>>
>>>>>  >> understand what you intend to use this for
>>>
>>>
>>> and what it would mean.
>>>
>>>>>  >> The UserLogin entity is part of the security
>>>
>>>
>>> data model and the only
>>>
>>>>>  >> reasons a Party would have multiple UserLogin
>>>
>>>
>>> records would be for
>>>
>>>>>  >> different permission sets or to change the
>>>
>>>
>>> UserLogin but still
>>>
>>>>>  >> reserve the old one for tracking/auditing
>>>
>>>
>>> purposes and such.
>>>
>>>>>  >>
>>>>>  >> -David
>>>>>  >>
>>>>>  >>
>>>>>  >> On Jan 21, 2006, at 6:09 PM, Vinay Agarwal
>>>
>>>
>>> wrote:
>>>
>>>>>  >>
>>>>>  >>> On second thought, it may be better to
>>>
>>>
>>> associate timezone with a
>>>
>>>>>  >>> UserLogin
>>>>>  >>> considering a party may have users in
>>>
>>>
>>> different locations. This of
>>>
>>>>>  >>> course,
>>>>>  >>> assumes that a single login is used by a
>>>
>>>
>>> single user who would have a
>>>
>>>>>  >>> preferred timezone. Would this be better
>>>
>>>
>>> than assigning it to a party?
>>>
>>>>>  >>>
>>>>>  >>> Regards,
>>>>>  >>> Vinay Agarwal
>>>>>  >>>
>>>>>  >>> -----Original Message-----
>>>>>  >>> From: users-bounces at lists.ofbiz.org
>>>
>>>
>>> [mailto:users-
>>>
>>>>>  >>> bounces at lists.ofbiz.org]
>>>>>  >>> On Behalf Of David E. Jones
>>>>>  >>> Sent: Friday, January 20, 2006 7:11 PM
>>>>>  >>> To: OFBiz Users / Usage Discussion
>>>>>  >>> Subject: Re: [OFBiz] Users - Party and
>>>
>>>
>>> Timezones
>>>
>>>>>  >>>
>>>>>  >>>
>>>>>  >>> This is a tricky one since it may be correct
>>>
>>>
>>> to say that a given
>>>
>>>>>  >>> Party corresponds to a single time zone. On
>>>
>>>
>>> the other hand, I guess
>>>
>>>>>  >>> it depends on what you want to do with it...
>>>
>>>
>>> it may be that having
>>>
>>>>>  >>> more than one time zone would mess up what
>>>
>>>
>>> you are trying to do. In
>>>
>>>>>  >>> general the time zone probably goes along
>>>
>>>
>>> best with the Postal
>>>
>>>>>  >>> Address, or perhaps even the Telecom Number.
>>>
>>>
>>> If you need a single
>>>
>>>>>  >>> field, or call it a "preferredTimeZone" or
>>>
>>>
>>> something along those
>>>
>>>>>  >>> lines to make it clear that it isn't
>>>
>>>
>>> supposed to be the only one,
>>>
>>>>>  >>> then putting it right on the Party entity is
>>>
>>>
>>> not a bad way to go.
>>>
>>>>>  >>>
>>>>>  >>> -David
>>>>>  >>>
>>>>>  >>>
>>>>>  >>> On Jan 20, 2006, at 1:44 PM, Vinay Agarwal
>>>
>>>
>>> wrote:
>>>
>>>>>  >>>
>>>>>  >>>> Hello,
>>>>>  >>>>
>>>>>  >>>> My application needs timezone setting for
>>>
>>>
>>> each party. I haven't
>>>
>>>>>  >>>> been able to
>>>>>  >>>> find any timezone setting for the party--is
>>>
>>>
>>> there one? If not,
>>>
>>>>>  >>>> what's the
>>>>>  >>>> preferred way for adding it? I assume
>>>
>>>
>>> modifying the party entity is
>>>
>>>>>  >>>> NOT the
>>>>>  >>>> preferred way. Any suggestions?
>>>>>  >>>>
>>>>>  >>>> Regards,
>>>>>  >>>> Vinay Agarwal