Rupert, That happens when the user shifts time zones while updating date fields.
I guess that is why in legal documents Date of Birth and Date of Death always come a registration of a Place of Birth and Place of Death so that the correct time zone can be associated. 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 10:12 AM, Rupert Howell <ruperthow...@provolve.com>wrote: > Correct date I should say - not time.... > > > On 1 April 2014 09:10, Rupert Howell <ruperthow...@provolve.com> wrote: > > > 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 > > > > > > -- > 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 >
