Mailing-List: contact dev-help@ofbiz.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ofbiz.apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: 
 <CADPkm85Lmi5DYK+o31mOe4ozZonc13xtuTqjM_P3E5O-Qb3QFg@mail.gmail.com>
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>
Date: Tue, 1 Apr 2014 09:27:57 +0100
Message-ID: 
 <CAGXgV2JBKj7AiDHUQN_ggt39YNzT9fYY9D+_CCtNyeDvcF_pTw@mail.gmail.com>
Subject: Re: Birthday's Change
From: Rupert Howell <ruperthowell@provolve.com>
To: "dev@ofbiz.apache.org" <dev@ofbiz.apache.org>
Content-Type: multipart/alternative; boundary=f46d0444ed6dfbce4604f5f6f11a

--f46d0444ed6dfbce4604f5f6f11a
Content-Type: text/plain; charset=ISO-8859-1

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

--f46d0444ed6dfbce4604f5f6f11a--