workEffort and timezone

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

workEffort and timezone

Chris Snow-3
When a workeffort is created in ofbiz, are the dates stored in UTC?

I.e. When a user creates a workeffort and enter the estimated start
date, will the estimated start date need to be entered by the user in UTC?

Many thanks,

Chris
Reply | Threaded
Open this post in threaded view
|

Re: workEffort and timezone

Adrian Crum-2
Chris,

Most all date-time fields in OFBiz are converted to the user's time zone. Date-time values are stored in the entities as java.sql.Timestamp - which always references GMT.

http://cwiki.apache.org/confluence/display/OFBTECH/Calendars%2C+Dates%2C+and+Times

-Adrian

--- On Wed, 1/20/10, Chris Snow <[hidden email]> wrote:

> From: Chris Snow <[hidden email]>
> Subject: workEffort and timezone
> To: [hidden email]
> Date: Wednesday, January 20, 2010, 3:40 AM
> When a workeffort is created in
> ofbiz, are the dates stored in UTC?
>
> I.e. When a user creates a workeffort and enter the
> estimated start date, will the estimated start date need to
> be entered by the user in UTC?
>
> Many thanks,
>
> Chris
>


     
Reply | Threaded
Open this post in threaded view
|

Re: workEffort and timezone

Chris Snow-3
Hi Adrian,

Have I understood this right? ...

A user wants to create a work effort.  In the create workeffort screen,
they add the current date and time for the estimatedStartDate, e.g.
2010-01-20 16:00:00 (CET)

The createWorkEffort service saves the estimatedStartDate using
"set-non-pk-fields".  This method ultimately calls an implementation of
LocalizedConverter which saves it as 2010-01-20 15:00:00 (GMT)

Many thanks,

Chris



Adrian Crum wrote:

> Chris,
>
> Most all date-time fields in OFBiz are converted to the user's time zone. Date-time values are stored in the entities as java.sql.Timestamp - which always references GMT.
>
> http://cwiki.apache.org/confluence/display/OFBTECH/Calendars%2C+Dates%2C+and+Times
>
> -Adrian
>
> --- On Wed, 1/20/10, Chris Snow <[hidden email]> wrote:
>
>  
>> From: Chris Snow <[hidden email]>
>> Subject: workEffort and timezone
>> To: [hidden email]
>> Date: Wednesday, January 20, 2010, 3:40 AM
>> When a workeffort is created in
>> ofbiz, are the dates stored in UTC?
>>
>> I.e. When a user creates a workeffort and enter the
>> estimated start date, will the estimated start date need to
>> be entered by the user in UTC?
>>
>> Many thanks,
>>
>> Chris
>>
>>    
>
>
>      
>  

Reply | Threaded
Open this post in threaded view
|

Re: workEffort and timezone

Adrian Crum
I was hoping the link I sent would convince you that you don't have to
be concerned about it. But anyways... yes - you are understanding it right.

-Adrian

snowch wrote:

> Hi Adrian,
>
> Have I understood this right? ...
>
> A user wants to create a work effort.  In the create workeffort screen,
> they add the current date and time for the estimatedStartDate, e.g.
> 2010-01-20 16:00:00 (CET)
>
> The createWorkEffort service saves the estimatedStartDate using
> "set-non-pk-fields".  This method ultimately calls an implementation of
> LocalizedConverter which saves it as 2010-01-20 15:00:00 (GMT)
>
> Many thanks,
>
> Chris
>
>
>
> Adrian Crum wrote:
>> Chris,
>>
>> Most all date-time fields in OFBiz are converted to the user's time
>> zone. Date-time values are stored in the entities as
>> java.sql.Timestamp - which always references GMT.
>>
>> http://cwiki.apache.org/confluence/display/OFBTECH/Calendars%2C+Dates%2C+and+Times 
>>
>>
>> -Adrian
>>
>> --- On Wed, 1/20/10, Chris Snow <[hidden email]> wrote:
>>
>>  
>>> From: Chris Snow <[hidden email]>
>>> Subject: workEffort and timezone
>>> To: [hidden email]
>>> Date: Wednesday, January 20, 2010, 3:40 AM
>>> When a workeffort is created in
>>> ofbiz, are the dates stored in UTC?
>>>
>>> I.e. When a user creates a workeffort and enter the
>>> estimated start date, will the estimated start date need to
>>> be entered by the user in UTC?
>>>
>>> Many thanks,
>>>
>>> Chris
>>>
>>>    
>>
>>
>>        
>
>