Rupert, You are right when you don't want to be to specific. But if you are specific and precise then a birthday needs to have a time zone associated.
Remember it is not the birthday itself that shifts, but your viewpoint of it when changing locations (meaning time zones). Regarding. 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:04 AM, Pierre Smits <pierre.sm...@gmail.com>wrote: > Hmm. > > Digging a bit deeper I see that birthday is persisted as a date. So that > shouldn't be creating issues. > > > 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:00 AM, 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 >>> >> >> >
