You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Rupert Howell <ru...@provolve.com> on 2014/04/01 09:46:44 UTC
Birthday's Change
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
Re: Birthday's Change
Posted by Rupert Howell <ru...@provolve.com>.
Adrian - this is definitely incorrect, the Birth Date field is stored as a
date field in Postgres so when OFbiz is converting the date to apply the
user's timezone it is taking the time as 00:00:0000 hence drastic changes
over a 1 hour time change. I could accept what you are saying if the
birthdate was a java.sql.Timestamp and if it was the time would HAVE to be
set to 12:00 (mid-day) UTC but it isn't.
Re: Birthday's Change
Posted by Rupert Howell <ru...@provolve.com>.
This behavior is clearly wrong. A 1 hour change in a timezone and people's
birthdays are wrong!
Postgres is storing the date fields as date fields. It is OFBiz that is
applying the LOCAL timezone information to the date on line 977 of
UtilDateTime.
On 1 April 2014 09:27, <ad...@sandglass-software.com> wrote:
> The date is stored as a java.sql.Timestamp - which is referenced to UTC.
> The UTC-referenced date is converted to the user's time zone during
> display. This is the intended behavior.
>
> -Adrian
>
>
> Quoting Rupert Howell <ru...@provolve.com>:
>
> 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
Re: Birthday's Change
Posted by ad...@sandglass-software.com.
The date is stored as a java.sql.Timestamp - which is referenced to
UTC. The UTC-referenced date is converted to the user's time zone
during display. This is the intended behavior.
-Adrian
Quoting Rupert Howell <ru...@provolve.com>:
> 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
>
Re: Birthday's Change
Posted by Pierre Smits <pi...@gmail.com>.
See section 'Time zones and birthdays' in
http://en.wikipedia.org/wiki/Birthday
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:21 AM, Pierre Smits <pi...@gmail.com>wrote:
> Rupert,
>
> That happens when the user shifts time zones while updating date fields.
>
> I guess that is why in legal documents Date of Birth and Date of Death
> always come a registration of a Place of Birth and Place of Death so that
> the correct time zone can be associated.
>
> 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 10:12 AM, Rupert Howell <ru...@provolve.com>wrote:
>
>> Correct date I should say - not time....
>>
>>
>> On 1 April 2014 09:10, Rupert Howell <ru...@provolve.com> wrote:
>>
>> > Hi Pierre,
>> >
>> > Yes I am aware of that. The 18 date fields are being stored correctly.
>> > They are however being displayed incorrectly because they are having the
>> > Timezone applied on line 977 UtilDateTime. If you carry out the test I
>> > described in the previous email. Birth Date on the person entity is the
>> > most obvious example of this. Set it to August 5th in GMT / BST /
>> European
>> > time. Change the timezone to -12, go back into update it again and in
>> the
>> > new TZ it says August 4th. The db stores the correct time so its only a
>> > very confusing display issue.
>> >
>> >
>> >
>> > On 1 April 2014 09:00, Pierre Smits <pi...@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
>> >
>>
>>
>>
>> --
>> 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
>>
>
>
Re: Birthday's Change
Posted by Pierre Smits <pi...@gmail.com>.
Rupert,
That happens when the user shifts time zones while updating date fields.
I guess that is why in legal documents Date of Birth and Date of Death
always come a registration of a Place of Birth and Place of Death so that
the correct time zone can be associated.
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 10:12 AM, Rupert Howell <ru...@provolve.com>wrote:
> Correct date I should say - not time....
>
>
> On 1 April 2014 09:10, Rupert Howell <ru...@provolve.com> wrote:
>
> > Hi Pierre,
> >
> > Yes I am aware of that. The 18 date fields are being stored correctly.
> > They are however being displayed incorrectly because they are having the
> > Timezone applied on line 977 UtilDateTime. If you carry out the test I
> > described in the previous email. Birth Date on the person entity is the
> > most obvious example of this. Set it to August 5th in GMT / BST /
> European
> > time. Change the timezone to -12, go back into update it again and in
> the
> > new TZ it says August 4th. The db stores the correct time so its only a
> > very confusing display issue.
> >
> >
> >
> > On 1 April 2014 09:00, Pierre Smits <pi...@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
> >
>
>
>
> --
> 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
>
Re: Birthday's Change
Posted by Rupert Howell <ru...@provolve.com>.
Correct date I should say - not time....
On 1 April 2014 09:10, Rupert Howell <ru...@provolve.com> wrote:
> Hi Pierre,
>
> Yes I am aware of that. The 18 date fields are being stored correctly.
> They are however being displayed incorrectly because they are having the
> Timezone applied on line 977 UtilDateTime. If you carry out the test I
> described in the previous email. Birth Date on the person entity is the
> most obvious example of this. Set it to August 5th in GMT / BST / European
> time. Change the timezone to -12, go back into update it again and in the
> new TZ it says August 4th. The db stores the correct time so its only a
> very confusing display issue.
>
>
>
> On 1 April 2014 09:00, Pierre Smits <pi...@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
>
--
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
Re: Birthday's Change
Posted by Rupert Howell <ru...@provolve.com>.
Hi Pierre,
Yes I am aware of that. The 18 date fields are being stored correctly. They
are however being displayed incorrectly because they are having the
Timezone applied on line 977 UtilDateTime. If you carry out the test I
described in the previous email. Birth Date on the person entity is the
most obvious example of this. Set it to August 5th in GMT / BST / European
time. Change the timezone to -12, go back into update it again and in the
new TZ it says August 4th. The db stores the correct time so its only a
very confusing display issue.
On 1 April 2014 09:00, Pierre Smits <pi...@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
Re: Birthday's Change
Posted by Pierre Smits <pi...@gmail.com>.
Gareth,
True. But if there is a misalignment of the db timezone and timezones
applied/determined in OFBiz (general - from properties, tenant setting,
organisation default or user specific) then overviews (displaying aspects
related as previous month/week, yesterday, today, tomorrow and next
week/month) relative to current date of the user might yield unexpected and
unwanted results.
Regards,
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 12:46 PM, <ga...@stannah.co.uk> wrote:
> Piere - SQL dates are stored without timezone information and dates are
> returned exactly the same with different default database timezones -
> unless you specifically convert the date field to a different timezone in
> SQL
>
> Such as
>
> Default timezone on our database
> set timezone to 'GB';
> select birth_date, timezone('Canada/Atlantic', birth_date) from person
> where birth_date is not null limit 100;
>
> Swap to see change in second column but birth_date is unaffected by the
> timezone in db
> set timezone to 'Canada/Atlantic';
> select birth_date, timezone('GB', birth_date) from person where birth_date
> is not null limit 100;
>
> In my opinion, this convention should be followed in ofbiz, you cannot
> correctly apply a timezone to a date only field without knowing the time!
>
>
>
> Adrian - We have had this issue for over a Year now and had a brief
> discussion with Hans about this a while back. My opinion it is the
> timezone being applied to java.sql.Date incorrectly that is at fault.
> Freemarker also has the same issue
>
> *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: Pierre Smits <pi...@gmail.com>
> To: dev@ofbiz.apache.org
> Date: 01/04/2014 11:15
> Subject: Re: Birthday's Change
> ------------------------------
>
>
>
> Rupert,
>
> Please create the JIRA issue. Irrespective of what the users timezone is,
> the date must always be stored in accordance with the timezone setting of
> the internal company used (with a failover (if not set) to the default of
> the tenant, which - if not set - fails over to the default of the OFBiz
> setup (from a .properties file). And yes, calculations to/from should
> always have 12:00 noon in mind.
>
> 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 12:10 PM, Rupert Howell <ruperthowell@provolve.com
> >wrote:
>
> > 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, <ga...@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 <ru...@provolve.com>
> > > To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
> >
> >
> >
> >
> > --
> > 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.
>
Re: Birthday's Change
Posted by ga...@stannah.co.uk.
Adrian - Yes how the db stores any data is irrelevant but the important
bit is how the date field is treated and returned to Java, I am merely
stating the fact that standard
SQL date fields have no time/timezone element and are unaffected by
timezone changes in the db. Time and timestamps can be though. Read
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt for more details
Can you give details on how you replicated? We only noticed the issue
because of changes between GMT and British Summer Time or vice versa. If
we had users from multiple countries using ofbiz and used their own
timezones, I believe any dates would show incorrectly for those west of
the UK.
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: adrian.crum@sandglass-software.com
To: dev@ofbiz.apache.org
Date: 01/04/2014 11:57
Subject: Re: Birthday's Change
How a DB manufacturer persists a date field is irrelevant. The issue
here is how Java handles the date type in the JDBC driver and
supporting code.
I repeat:
I can reproduce the problem using a time zone with ZERO OFFSET, so
this is not a problem caused by applying a time zone to a date. More
likely, it is a problem with the WRONG time zone being applied to a
date.
-Adrian
Quoting gareth_carter@stannah.co.uk:
> Piere - SQL dates are stored without timezone information and dates are
> returned exactly the same with different default database timezones -
> unless you specifically convert the date field to a different timezone
in
> SQL
>
> Such as
>
> Default timezone on our database
> set timezone to 'GB';
> select birth_date, timezone('Canada/Atlantic', birth_date) from person
> where birth_date is not null limit 100;
>
> Swap to see change in second column but birth_date is unaffected by the
> timezone in db
> set timezone to 'Canada/Atlantic';
> select birth_date, timezone('GB', birth_date) from person where
birth_date
> is not null limit 100;
>
> In my opinion, this convention should be followed in ofbiz, you cannot
> correctly apply a timezone to a date only field without knowing the
time!
>
>
>
> Adrian - We have had this issue for over a Year now and had a brief
> discussion with Hans about this a while back. My opinion it is the
> timezone being applied to java.sql.Date incorrectly that is at fault.
> Freemarker also has the same issue
>
>
>
> 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: Pierre Smits <pi...@gmail.com>
> To: dev@ofbiz.apache.org
> Date: 01/04/2014 11:15
> Subject: Re: Birthday's Change
>
>
>
> Rupert,
>
> Please create the JIRA issue. Irrespective of what the users timezone
is,
> the date must always be stored in accordance with the timezone setting
of
> the internal company used (with a failover (if not set) to the default
of
> the tenant, which - if not set - fails over to the default of the OFBiz
> setup (from a .properties file). And yes, calculations to/from should
> always have 12:00 noon in mind.
>
> 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 12:10 PM, Rupert Howell
> <ru...@provolve.com>wrote:
>
>> 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, <ga...@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 <ru...@provolve.com>
>> > To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>>
>>
>>
>>
>> --
>> 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.
>
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.
Re: Birthday's Change
Posted by ad...@sandglass-software.com.
How a DB manufacturer persists a date field is irrelevant. The issue
here is how Java handles the date type in the JDBC driver and
supporting code.
I repeat:
I can reproduce the problem using a time zone with ZERO OFFSET, so
this is not a problem caused by applying a time zone to a date. More
likely, it is a problem with the WRONG time zone being applied to a
date.
-Adrian
Quoting gareth_carter@stannah.co.uk:
> Piere - SQL dates are stored without timezone information and dates are
> returned exactly the same with different default database timezones -
> unless you specifically convert the date field to a different timezone in
> SQL
>
> Such as
>
> Default timezone on our database
> set timezone to 'GB';
> select birth_date, timezone('Canada/Atlantic', birth_date) from person
> where birth_date is not null limit 100;
>
> Swap to see change in second column but birth_date is unaffected by the
> timezone in db
> set timezone to 'Canada/Atlantic';
> select birth_date, timezone('GB', birth_date) from person where birth_date
> is not null limit 100;
>
> In my opinion, this convention should be followed in ofbiz, you cannot
> correctly apply a timezone to a date only field without knowing the time!
>
>
>
> Adrian - We have had this issue for over a Year now and had a brief
> discussion with Hans about this a while back. My opinion it is the
> timezone being applied to java.sql.Date incorrectly that is at fault.
> Freemarker also has the same issue
>
>
>
> 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: Pierre Smits <pi...@gmail.com>
> To: dev@ofbiz.apache.org
> Date: 01/04/2014 11:15
> Subject: Re: Birthday's Change
>
>
>
> Rupert,
>
> Please create the JIRA issue. Irrespective of what the users timezone is,
> the date must always be stored in accordance with the timezone setting of
> the internal company used (with a failover (if not set) to the default of
> the tenant, which - if not set - fails over to the default of the OFBiz
> setup (from a .properties file). And yes, calculations to/from should
> always have 12:00 noon in mind.
>
> 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 12:10 PM, Rupert Howell
> <ru...@provolve.com>wrote:
>
>> 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, <ga...@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 <ru...@provolve.com>
>> > To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>>
>>
>>
>>
>> --
>> 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.
>
Re: Birthday's Change
Posted by ga...@stannah.co.uk.
Piere - SQL dates are stored without timezone information and dates are
returned exactly the same with different default database timezones -
unless you specifically convert the date field to a different timezone in
SQL
Such as
Default timezone on our database
set timezone to 'GB';
select birth_date, timezone('Canada/Atlantic', birth_date) from person
where birth_date is not null limit 100;
Swap to see change in second column but birth_date is unaffected by the
timezone in db
set timezone to 'Canada/Atlantic';
select birth_date, timezone('GB', birth_date) from person where birth_date
is not null limit 100;
In my opinion, this convention should be followed in ofbiz, you cannot
correctly apply a timezone to a date only field without knowing the time!
Adrian - We have had this issue for over a Year now and had a brief
discussion with Hans about this a while back. My opinion it is the
timezone being applied to java.sql.Date incorrectly that is at fault.
Freemarker also has the same issue
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: Pierre Smits <pi...@gmail.com>
To: dev@ofbiz.apache.org
Date: 01/04/2014 11:15
Subject: Re: Birthday's Change
Rupert,
Please create the JIRA issue. Irrespective of what the users timezone is,
the date must always be stored in accordance with the timezone setting of
the internal company used (with a failover (if not set) to the default of
the tenant, which - if not set - fails over to the default of the OFBiz
setup (from a .properties file). And yes, calculations to/from should
always have 12:00 noon in mind.
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 12:10 PM, Rupert Howell
<ru...@provolve.com>wrote:
> 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, <ga...@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 <ru...@provolve.com>
> > To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>
>
>
>
> --
> 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.
Re: Birthday's Change
Posted by Pierre Smits <pi...@gmail.com>.
Rupert,
Please create the JIRA issue. Irrespective of what the users timezone is,
the date must always be stored in accordance with the timezone setting of
the internal company used (with a failover (if not set) to the default of
the tenant, which - if not set - fails over to the default of the OFBiz
setup (from a .properties file). And yes, calculations to/from should
always have 12:00 noon in mind.
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 12:10 PM, Rupert Howell <ru...@provolve.com>wrote:
> 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, <ga...@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 <ru...@provolve.com>
> > To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>
>
>
>
> --
> 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
>
Re: Birthday's Change
Posted by Jacques Le Roux <ja...@les7arts.com>.
Great, thanks Adrian
Jacques
Le 01/04/2014 13:39, adrian.crum@sandglass-software.com a écrit :
> Jacques,
>
> I am analyzing the problem. The discussion so far reflects a lack of understanding of how Java's date/time handling works, so it would be best if I
> take care of this myself.
>
> -Adrian
>
>
> Quoting Jacques Le Roux <ja...@les7arts.com>:
>
>> 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.crum@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 <ru...@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, <ga...@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 <ru...@provolve.com>
>>>>> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>>
>>>
>>
>> --
>> 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
Re: Birthday's Change
Posted by ad...@sandglass-software.com.
Jacques,
I am analyzing the problem. The discussion so far reflects a lack of
understanding of how Java's date/time handling works, so it would be
best if I take care of this myself.
-Adrian
Quoting Jacques Le Roux <ja...@les7arts.com>:
> 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.crum@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 <ru...@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, <ga...@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 <ru...@provolve.com>
>>>> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>>
>
> --
> Jacques Le Roux
> 400E Chemin de la Mouline
> 34560 Poussan
> 33+(0)4 67 51 19 38
> 33+(0)6 11 19 50 28
>
>
Re: Birthday's Change
Posted by Rupert Howell <ru...@provolve.com>.
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 <ja...@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 <ja...@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.crum@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 <ru...@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, <ga...@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 <ru...@provolve.com>
>>>>>> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>> 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: ruperthowell@provolve.com
w: http://www.provolve.com
Re: Birthday's Change
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <ja...@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.crum@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 <ru...@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, <ga...@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 <ru...@provolve.com>
>>>>> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>>
>>>
>>>
>>>
>> --
>> 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
Re: Birthday's Change
Posted by Rupert Howell <ru...@provolve.com>.
I've just set a custom time period up for the following dates:
4/3/2014 - 30/4/2014
Its being persisted as 2014-03-04 to the 2014-04-03
The below is a true failure.
On 5 April 2014 11:28, Jacques Le Roux <ja...@les7arts.com> wrote:
> 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.simpleTypeConvertTestSingleMul
> ti(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.crum@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 <ru...@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 <ja...@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.crum@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 <ru...@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, <ga...@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 <ru...@provolve.com>
>>>>>>> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>> 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: 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
Re: Birthday's Change
Posted by Rupert Howell <ru...@provolve.com>.
I've reopened the Jira for this.
I don't believe this fix will actually make any difference anyway.
On 7 April 2014 09:48, <ga...@stannah.co.uk> wrote:
> 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 <ja...@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.crum@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 <ru...@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 <ja...@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.crum@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 <ru...@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, <ga...@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 <ru...@provolve.com>
> >>>>>> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> 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
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>> --
> >>> 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: 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.
Re: Birthday's Change
Posted by ad...@sandglass-software.com.
Fixed in rev 1585574. Thanks!
-Adrian
Quoting gareth_carter@stannah.co.uk:
> 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 <ja...@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.crum@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 <ru...@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 <ja...@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.crum@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 <ru...@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, <ga...@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 <ru...@provolve.com>
>>>>>>> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> 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: 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.
>
Re: Birthday's Change
Posted by ga...@stannah.co.uk.
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 <ja...@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.crum@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 <ru...@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 <ja...@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.crum@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 <ru...@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, <ga...@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 <ru...@provolve.com>
>>>>>> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>> --
>>> 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: 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.
Re: Birthday's Change
Posted by Jacques Le Roux <ja...@les7arts.com>.
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.crum@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 <ru...@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 <ja...@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.crum@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 <ru...@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, <ga...@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 <ru...@provolve.com>
>>>>>> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>> --
>>> 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: ruperthowell@provolve.com
>> w: http://www.provolve.com
>>
>
>
>
>
--
Re: Birthday's Change
Posted by ad...@sandglass-software.com.
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 <ru...@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 <ja...@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.crum@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 <ru...@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, <ga...@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 <ru...@provolve.com>
>>>>> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>>
>> --
>> 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: ruperthowell@provolve.com
> w: http://www.provolve.com
>
Re: Birthday's Change
Posted by Rupert Howell <ru...@provolve.com>.
Perfect - thanks Adrian.
Rupert Howell
Provolve Ltd.
Technopole
Kingston Crescent
Portsmouth
PO2 8FA
07909 685308
http://www.provolve.com
> On 5 Apr 2014, at 10:56, "adrian.crum@sandglass-software.com" <ad...@sandglass-software.com> wrote:
>
> 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 <ru...@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 <ja...@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.crum@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 <ru...@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, <ga...@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 <ru...@provolve.com>
>>>>>> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>> --
>>> 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: ruperthowell@provolve.com
>> w: http://www.provolve.com
>
>
>
Re: Birthday's Change
Posted by Rupert Howell <ru...@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 <ja...@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.crum@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 <ru...@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, <ga...@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 <ru...@provolve.com>
>>>> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>
>>
>>
>>
> --
> 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: ruperthowell@provolve.com
w: http://www.provolve.com
Re: Birthday's Change
Posted by Jacques Le Roux <ja...@les7arts.com>.
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.crum@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 <ru...@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, <ga...@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 <ru...@provolve.com>
>>> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>>
>>
>>
>>
>> --
>> 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
>>
>
>
>
>
--
Jacques Le Roux
400E Chemin de la Mouline
34560 Poussan
33+(0)4 67 51 19 38
33+(0)6 11 19 50 28
Re: Birthday's Change
Posted by ad...@sandglass-software.com.
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 <ru...@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, <ga...@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 <ru...@provolve.com>
>> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>
>
>
>
> --
> 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
>
Re: Birthday's Change
Posted by Rupert Howell <ru...@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, <ga...@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 <ru...@provolve.com>
> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
--
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
Re: Birthday's Change
Posted by ad...@sandglass-software.com.
Thank you Gareth - that is helpful. I can reproduce the date change
using UTC - so there must be another problem here (since UTC has no
offset).
-Adrian
Quoting gareth_carter@stannah.co.uk:
> 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 <ru...@provolve.com>
> To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
>
Re: Birthday's Change
Posted by ga...@stannah.co.uk.
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 <ru...@provolve.com>
To: "dev@ofbiz.apache.org" <de...@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 <pi...@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.
Re: Birthday's Change
Posted by Rupert Howell <ru...@provolve.com>.
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 <pi...@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
Re: Birthday's Change
Posted by Pierre Smits <pi...@gmail.com>.
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 <pi...@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 <pi...@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 <ru...@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
>>>
>>
>>
>
Re: Birthday's Change
Posted by Pierre Smits <pi...@gmail.com>.
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 <pi...@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 <ru...@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
>>
>
>
Re: Birthday's Change
Posted by Pierre Smits <pi...@gmail.com>.
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 <ru...@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
>