You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Leon Rosenberg <st...@anotheria.net> on 2005/08/25 11:40:18 UTC
Re: basic date field question
On Thu, 2005-08-25 at 12:34 +0200, Rivka Shisman wrote:
> Hi friends
>
Shalom,
>
>
> I'm puzzled with a basic design problem:
>
>
>
> I have a VO - say StudentVO - that has a property -> birth_date.
>
>
>
> Should the birth_date property be of type String (and then in the DAO
> convert it to java.sql.Date) -
The value object should have business knowledge, and therefor usage of
the string isn't quite appropriate.
On the other hand, java.sql.Date is a rather ugly thing. Personally I
prefer to store date variables as longs in milliseconds, it's most
easier to work with, calculating date intervals is quite easy, and you
can convert it to a java.util.Date anytime.
So, my proposal would be:
StudentVO(){
private long birthDate;
public long getBirthDate();
public java.util.Date getBirthDateAsDate(){
return new Date(getBirthDate()); //or do it with calendar, or whatever.
}
In your db you should store it as long then.
regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: basic date field question
Posted by Gareth Evans <ga...@msoft.co.uk>.
A slight tweak to that...
StudentVO(){
private Date birthDate;
public long getBirthDate() {
return birthDate.getTime();
}
public java.util.Date getBirthDateAsDate(){
return birthDate;
}
Why?
Because this way two subsequent calls to 'getBirthDateAsDate' will return the same object i.e.
You can then modify the date using a calendar and the correct values within the StudentVO object
will be updated.
Gareth
Leon Rosenberg wrote:
> On Thu, 2005-08-25 at 12:34 +0200, Rivka Shisman wrote:
>
>>Hi friends
>>
>
>
> Shalom,
>
>
>>
>>
>>I'm puzzled with a basic design problem:
>>
>>
>>
>>I have a VO - say StudentVO - that has a property -> birth_date.
>>
>>
>>
>>Should the birth_date property be of type String (and then in the DAO
>>convert it to java.sql.Date) -
>
>
>
> The value object should have business knowledge, and therefor usage of
> the string isn't quite appropriate.
> On the other hand, java.sql.Date is a rather ugly thing. Personally I
> prefer to store date variables as longs in milliseconds, it's most
> easier to work with, calculating date intervals is quite easy, and you
> can convert it to a java.util.Date anytime.
>
> So, my proposal would be:
> StudentVO(){
> private long birthDate;
>
> public long getBirthDate();
>
> public java.util.Date getBirthDateAsDate(){
> return new Date(getBirthDate()); //or do it with calendar, or whatever.
> }
>
>
> In your db you should store it as long then.
>
> regards
> Leon
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
--
Gareth Evans
MSoft eSolutions Limited
Technology Centre
Inward Way
Rossmore Business Park
Ellesmere Port
Cheshire
CH65 3EN
--
Tel: +44 (0)870 0100 704
Fax: +44 (0)870 9010 705
E-Mail: gareth@msoft.co.uk
Web: www.msoft.co.uk
----------------------------------------------
Terms:
Please note that any prices quoted within this e-mail are subject to VAT.
All program details and code described in this e-mail are subject to
copyright © of MSoft eSolutions Limited and remain the intellectual
property of MSoft eSolutions Limited.
Any proposal or pricing information contained within this e-mail are
subject to MSoft eSolutions' Terms and Conditions
----------------------------------------------
Disclaimer:
This message is intended only for use of the addressee. If this message
was sent to you in error, please notify the sender and delete this
message. MSoft eSolutions Limited cannot accept responsibility for viruses,
so please scan attachments. Views expressed in this message do not
necessarily reflect those of MSoft eSolutions Limited who will not
necessarily be bound by its contents.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org