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
