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.
