ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gareth_car...@stannah.co.uk
Subject Re: Birthday's Change
Date Tue, 01 Apr 2014 08:45:04 GMT
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.

Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message