Perfect - thanks Adrian. Rupert Howell
Provolve Ltd. Technopole Kingston Crescent Portsmouth PO2 8FA 07909 685308 http://www.provolve.com > On 5 Apr 2014, at 10:56, "adrian.c...@sandglass-software.com" > <adrian.c...@sandglass-software.com> wrote: > > Fixed, revision 1585033. > > Rupert - I apologize if my reply offended you. I was trying to stop > the spread of misinformation. > > As I tried to point out, the problem was not due to applying a > timezone to the date formatter. Keep in mind the date formatter > contains a Calendar instance, and that Calendar instance contains a > TimeZone instance. If you don't specify a time zone, then the system > default it used. > > The problem was due to how java.sql.Date behaves when it contains a > time component. I fixed the conversion framework to mask out the time > component. > > -Adrian > > > Quoting Rupert Howell <ruperthow...@provolve.com>: > >> Jacques. >> >> The problem I am describing exists in 13.07. I can check if it exists in >> 12.04 but I strongly suspect it will. >> >> Adrian. >> >> Our discussion so far does not indicate a lack of understanding - we have >> spent a fair amount of time looking into this and investigating it. Your >> last comment was unnecessary. I do not think you should be actively >> resisting users from looking into issues with statements like that. >> >> >>> On 1 April 2014 12:17, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote: >>> >>> Rupert, Gareth, >>> >>> Can we qualify "recently"? I guess R13.07 works? >>> Then by dichotomy it should not be too hard to find a range of concerned >>> commits and then the culprit. >>> The result of these research would fit in the Jira >>> >>> Thanks >>> >>> Jacques >>> >>> Le 01/04/2014 12:17, adrian.c...@sandglass-software.com a écrit : >>> >>>> Please do not provide a patch. The problem is not caused by applying a >>>> time zone to a date - it is caused by something else. All of this was >>>> working correctly until now, so there must be a problem somewhere else. >>>> >>>> -Adrian >>>> >>>> >>>> Quoting Rupert Howell <ruperthow...@provolve.com>: >>>> >>>> Thanks Gareth that was put much more eloquently. >>>>> Adrian / Pierre are you happy there's an issue here and I'll raise a Jira >>>>> and submit a patch. >>>>> >>>>> Can we discuss if there's a need for for a new "date-fixed" field type >>>>> that >>>>> never has the timezone applied to the date format on display or whether >>>>> we >>>>> should use the existing date as a container for a specific moment in time >>>>> that is completely TZ independent. In my mind the latter is how it should >>>>> be since java.util.Date has no TZ information attached to it I cant see >>>>> how >>>>> formatting it with a timezone is atall beneficial. >>>>> >>>>> Best Regards, >>>>> >>>>> >>>>> On 1 April 2014 09:45, <gareth_car...@stannah.co.uk> wrote: >>>>> >>>>> Hi all >>>>>> >>>>>> Me and Rupert have been looking at this as we've had this issue for a >>>>>> while with specifically the Birth Date field - but any date only fields >>>>>> will have this issue. >>>>>> >>>>>> The birth date field is date only in ofbiz and in the database >>>>>> java.sql.Date is returned from jdbc drivers when the field is SQL date, >>>>>> the date will be set but the time will always be 00:00:00. The >>>>>> java.sql.Date is only there to represent date only component of >>>>>> java,util.Date (java.sql.Date overrides toString method to return only >>>>>> the >>>>>> date) >>>>>> Because java.sql.Date extends java.util.Date and can be used in >>>>>> DateFormat >>>>>> class, applying a timezone with a negative offset will shift the day to >>>>>> the >>>>>> previous day because time is ALWAYS set to 00:00:00 >>>>>> >>>>>> This also occurs in freemarker if you convert a java.sql.Date to a >>>>>> string >>>>>> using syntax such as ${date?string} where date is a java.sql.Date >>>>>> object. I >>>>>> have created a fix in my fork at >>>>>> https://github.com/gareth-carter/freemarker >>>>>> >>>>>> *Gareth Carter * >>>>>> >>>>>> *Software Development Analyst* >>>>>> >>>>>> *Stannah Management Services Ltd* >>>>>> >>>>>> *IT* >>>>>> >>>>>> *Ext:* >>>>>> >>>>>> 7036 >>>>>> >>>>>> *Tel:* >>>>>> >>>>>> 01264 364311 >>>>>> >>>>>> *Fax:* >>>>>> >>>>>> >>>>>> >>>>>> Please consider the environment before printing this email. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: Rupert Howell <ruperthow...@provolve.com> >>>>>> To: "dev@ofbiz.apache.org" <dev@ofbiz.apache.org> >>>>>> Date: 01/04/2014 09:27 >>>>>> Subject: Re: Birthday's Change >>>>>> ------------------------------ >>>>>> >>>>>> >>>>>> >>>>>> My birth date is my birth date wherever I am in the world - it is not >>>>>> relative. My passport doesn't change as I travel through Timezones. Yet >>>>>> if >>>>>> I view my passport information is OFBiz it will change, >>>>>> Dates need to be viewed as dates and be totally independent of >>>>>> timezones. I >>>>>> cannot think of a single reason why you would want to be specific with >>>>>> dates. If you do want to be specific and have them change as to where >>>>>> you >>>>>> view them from - you'd just use Timestamps. >>>>>> >>>>>> >>>>>> On 1 April 2014 09:12, Pierre Smits <pierre.sm...@gmail.com> wrote: >>>>>> >>>>>> > 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 >>>>>> > >>> >>>>>> > >> >>>>>> > >> >>>>>> > > >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> This email is intended only for the above addressee. It may contain >>>>>> privileged information. If you are not the addressee you must not copy, >>>>>> distribute, disclose or use any of the information in it. If you have >>>>>> received it in error, please delete it and notify the sender. >>>>>> >>>>>> Stannah Lift Holdings Ltd registered No. 686996, Stannah Management >>>>>> Services Ltd registered No. 2483693, Stannah Lift Services Ltd >>>>>> registered >>>>>> No. 1189799, Stannah Microlifts Ltd registered No. 964804, Stannah Lifts >>>>>> Ltd registered No. 1189836, Stannah Stairlifts Ltd registered No. >>>>>> 1401451. >>>>>> >>>>>> All registered offices at Watt Close, East Portway, Andover, Hampshire, >>>>>> SP10 3SD, England. >>>>>> >>>>>> All Registered in England and Wales. >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>> -- >>> Jacques Le Roux >>> 400E Chemin de la Mouline >>> 34560 Poussan >>> 33+(0)4 67 51 19 38 >>> 33+(0)6 11 19 50 28 >> >> >> -- >> 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 > > >
