Mailing-List: contact dev-help@ofbiz.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ofbiz.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <20140407144610.19564j0ovi9815z6@secure172.sgcpanel.com>
Date: Mon, 07 Apr 2014 14:46:10 -0500
From: adrian.crum@sandglass-software.com
To: dev@ofbiz.apache.org
Subject: Re: Birthday's Change
References: 
 <CAGXgV2KD-1fAojzPz851PzH8UF_skNjn4xs8rhDvgXrk_BULpg@mail.gmail.com>
 <CADPkm87E23voN9MNTD0GjLxxCzMMN=aku-9DYZsyssHQQLNf=A@mail.gmail.com>
 <CADPkm852EQgqsDRD2vGv6OGjxW_2or68nTyAFXeUBhCADRLFbw@mail.gmail.com>
 <CADPkm85Lmi5DYK+o31mOe4ozZonc13xtuTqjM_P3E5O-Qb3QFg@mail.gmail.com>
 <CAGXgV2JBKj7AiDHUQN_ggt39YNzT9fYY9D+_CCtNyeDvcF_pTw@mail.gmail.com>
 <OF6AFD7CB0.98B9A197-ON80257CAD.002ECCD8-80257CAD.0030129A@stannah.co.uk>
 <CAGXgV2L4HxFuwJcC6tXMzzqZd=DTQduFso6R_Hp9ekJdKC0zaA@mail.gmail.com>
 <20140401051736.20605r5rmdo1ori8@secure172.sgcpanel.com>
 <533AA063.8010403@les7arts.com>
 <CAGXgV2LRD0qkjUniKcD1BYU0OcskzmivZxKySXmf6iWC209_sA@mail.gmail.com>
 <20140405045605.13711wvr8x1o60c5@secure172.sgcpanel.com>
 <533FDAEA.8020203@les7arts.com>
 <OF575C6378.B3AB754B-ON80257CB3.00303259-80257CB3.00306280@stannah.co.uk>
In-Reply-To: 
 <OF575C6378.B3AB754B-ON80257CB3.00303259-80257CB3.00306280@stannah.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8;
 DelSp="Yes";
 format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) H3 (4.3.11)

Fixed in rev 1585574. Thanks!

-Adrian


Quoting gareth_carter@stannah.co.uk:

> 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.roux@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.crum@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 <ruperthowell@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.roux@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.crum@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 <ruperthowell@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_carter@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 <ruperthowell@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.smits@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.smits@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.smits@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 <
>>>>>>> > ruperthowell@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:  ruperthowell@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:  ruperthowell@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:  ruperthowell@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:  ruperthowell@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.
>