Re: Date time classes for new Wonder frameworks
Re: Date time classes for new Wonder frameworks
- Subject: Re: Date time classes for new Wonder frameworks
- From: Pascal Robert <email@hidden>
- Date: Fri, 19 Oct 2012 20:50:44 -0400
Le 2012-10-19 à 20:04, Paul Hoadley <email@hidden> a écrit :
> On 20/10/2012, at 9:21 AM, Pascal Robert <email@hidden> wrote:
>
>> I'm working on ERGroupware, and I was wondering if I should use NSTimestamp. I started using it to make it more "WO friendly" but I have to fu**ing convert everything because the dates for ical4j, Zimbra and MS Exchange expect a java.util.Date or java.util.Calendar, hence the need to create or convert NSTimestamp.
>>
>> So the question: for new frameworks that will go in Wonder, should we keep using NSTimestamp or should we use something else?
>
> If you're talking about code internal to your new framework, then presumably it doesn't matter. But if it's code that's going to interface with existing frameworks, aren't you creating an interoperability problem given that every existing framework uses NSTimestamp? What am I missing here?
It's mainly « external ». The thing is that I have classes that regroup all attributes of a iCalendar file, an appointment or task in Zimbra (SOAP API) or Exchange Web Services. Of source, those 3 sources use different date time classes… And I end up with things like:
NSTimestamp eventStartDate = event.startTime();
Calendar startDate = GregorianCalendar.getInstance();
startDate.setTime(eventStartDate);
calendarItem.setStart(startDate);
But the question is mainly about if we should move away from NSTimestamp in new frameworks for Wonder, or should we move to something else, for « exposed » date time attributes (that is, attributes that would be editable in a WOTextField, by REST, etc.).
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden