I've reopened the Jira for this. I don't believe this fix will actually make any difference anyway.
On 7 April 2014 09:48, <gareth_car...@stannah.co.uk> wrote: > The reason for this is because the mod Adrian Made for OFBIZ-5608, which > calls getYear(), getMonth(), getDay() of java.util.Date, however getDay() > returns the day of week not of the month, getDate() returns day of month. > > *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: Jacques Le Roux <jacques.le.r...@les7arts.com> > To: dev@ofbiz.apache.org > Date: 05/04/2014 11:37 > Subject: Re: Birthday's Change > ------------------------------ > > > > Thanks Adrian! > > Is that a false failure or a test to adapt? > http://ci.apache.org/projects/ofbiz/logs/trunk/html/ > > Plain text: > basetests testString Failure > String->java.sql.Date(:0):default-timezone/locale expected:<1969-12-31> but > was:<1969-12-03> > > junit.framework.AssertionFailedError: > String->java.sql.Date(:0):default-timezone/locale expected:<1969-12-31> but > was:<1969-12-03> > at > org.ofbiz.base.test.GenericTestCaseBase.assertEquals(GenericTestCaseBase.java:343) > at > org.ofbiz.base.util.test.ObjectTypeTests.simpleTypeConvertTest(ObjectTypeTests.java:114) > at > org.ofbiz.base.util.test.ObjectTypeTests.simpleTypeConvertTestSingleMulti(ObjectTypeTests.java:142) > at > org.ofbiz.base.util.test.ObjectTypeTests.testString(ObjectTypeTests.java:230) > at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:147) > at org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:239) > at org.ofbiz.base.start.Start.startStartLoaders(Start.java:340) > at org.ofbiz.base.start.Start.start(Start.java:382) > at org.ofbiz.base.start.Start.main(Start.java:122) > > Jacques > > Le 05/04/2014 11:56, adrian.c...@sandglass-software.com a écrit : > > 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 > >> > > > > > > > > > > -- > > > > > 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.
