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
