You may also want to have a look at the Calendar class as a method of generating your Date objects. There are several methods that are very useful for getting Locale times, so users would get there local time, not the time where you app is located.
If you have the Calendar in a Static class as Cedric sugested and write your own methods for standard getDate() and getDate(Locale l), you will find the time complexity around the 2-5 millisecond maker for the first, and 10-12 milliseconds for the second. Not too costly :-) Cheers Simon ----- Original Message ----- From: "Cedric Dumoulin" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Friday, March 28, 2003 9:48 AM Subject: Re: Questions concerning Tiles > > Hi Guillaume, > > It is hard to say, I have never evaluated the cost of creation of a > new Date object. > You need to evaluate this cost, and compare it against a solution > where you cache the object. Maybe the Date implementation already do a > kind of caching ! > If not, it should be simple to create a singleton class(a static one) > with one method: getDate(). This method cache the real object, and take > care of updating it daily :-). > > Cedric > > COMPAGNON GUILLAUME wrote: > > >Cédric, > >is that make sense to define a bean type for printing the today date with > >the scope of the application ( in order not to instanciate the Date each > >time) ? > > > >Thx! > >Guillaume > > > > > >---------------------------------------------------- > >Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'intention exclusive de ses destinataires. > >Toute utilisation ou diffusion non autorisee est interdite.Tout message electronique est susceptible d'alteration. > >Le CREDIT DU NORD et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. > >This message and any attachments ( the "message") are confidential and intended solely for the addressees. > >Any unauthorised use or dissemination is prohibited.E-mails are susceptible to alteration. > >Neither CREDIT DU NORD nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. > >---------------------------------------------------- > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
