Hi Pierre, Yes I am aware of that. The 18 date fields are being stored correctly. They are however being displayed incorrectly because they are having the Timezone applied on line 977 UtilDateTime. If you carry out the test I described in the previous email. Birth Date on the person entity is the most obvious example of this. Set it to August 5th in GMT / BST / European time. Change the timezone to -12, go back into update it again and in the new TZ it says August 4th. The db stores the correct time so its only a very confusing display issue.
On 1 April 2014 09:00, Pierre Smits <pierre.sm...@gmail.com> wrote: > Rupert, > > A date should not be stored as a date-time, but as a date. This appears > throughout the entire spectrum of apps where dates are intended. Over 600 > entity fields are designated as date-time, 18 entity fields are designated > as date and 8 as time. > > Regards, > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > > On Tue, Apr 1, 2014 at 9:46 AM, Rupert Howell <ruperthow...@provolve.com > >wrote: > > > There's a definite problem with the way the dates are displayed in OFBiz. > > If you enter a birthday with your local timezone set to UTC, then change > > the timezone to -12, the birthday changes to the previous day. This is > > clearly wrong and is really apparent if you have your Server Timezone set > > to GB. If the birthday is within BST (April - October) and you are in GMT > > (Nov - March) they all appear incorrectly and vice versa. > > > > Ultimately this is caused by line 977 UtilDateTime > > > > f.setTimeZone(tz); > > > > Can anyone think of a legitimate reason why a date would have a timezone > > applied? A date is a date. January 1st is January 1st no matter where in > > the world you are. I would have thought if you want a date to be timezone > > dependent you'd use a Timestamp. > > > > I could patch line 666 of ModelFormField but I think it would be better > to > > actually change the UtilDateTime method.. > > -- > > Rupert Howell > > > > Provolve Ltd > > Front Office, Deale House, 16 Lavant Street, Petersfield, GU32 3EW, UK > > > > t: 01730 267868 / m: 079 0968 5308 > > e: ruperthow...@provolve.com > > w: http://www.provolve.com > > > -- Rupert Howell Provolve Ltd Front Office, Deale House, 16 Lavant Street, Petersfield, GU32 3EW, UK t: 01730 267868 / m: 079 0968 5308 e: ruperthow...@provolve.com w: http://www.provolve.com
