I've added a Jira for this.
https://issues.apache.org/jira/browse/OFBIZ-5608
I've replicated it now in trunk, 13.07 and 12.04.
Regards,
On 1 April 2014 13:21, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote:
> Thanks Rupert,
>
> So this contradicts Adrian's assertion so far
>
> Let's see...
>
> Jacques
>
> Le 01/04/2014 14:01, Rupert Howell a écrit :
>
>> 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
>>>
>>>
>>>
>>
> --
> 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
