I've just set a custom time period up for the following dates: 4/3/2014 - 30/4/2014
Its being persisted as 2014-03-04 to the 2014-04-03 The below is a true failure. On 5 April 2014 11:28, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote: > 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.simpleTypeConvertTestSingleMul > ti(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 >>> >>> >> >> >> >> > -- > -- 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
