Re: Consideration for Date management

On Nov 11, 2004, at 5:51 AM, Jean-Fran=E7ois Veillette wrote:

> Summary :
>
> How do efficiently deal with gregorian date, when we absolutely (by=20
> design) do not care about time issue ?
Dates, times, and timezones are a nightmare!


> How about :
> In EOModeler, use a custom class (custom data type) to represent=20
> gregorian calendar attribute, to avoid dealing with time, timezone and=20=

> daylight saving.  This custom class (name it GCDate, for=20
> GregorianCalendarDate) would not care at all about time issue, and=20
> would be able to calculate dates.
>
> What do you think about this ?
>
That is also what I have been thinking of.


> It it worth the trouble ?
>
Almost certainly.


> Is it something you tried but couldn't get it to work correctly=20
> because of ... ?
>
Lack of time.  :-)


> Is it something you have successfully implemented ?
>
At first blush you might be able to get away with an NSTimestamp=20
subclass and just always force the time and timezone portions to be a=20
constant value.  JDBC is going to interfere as it has no concept of=20
timezone.


> Long :
>
> We frequently have to deal with date (year/month/day) using=20
> nstimestamp=20
> (year/month/day/hour/minutes/secons/milliseconds/timezone), thus we=20
> always deal with object being on the same date, but not being equals=20=

> because of differences in milliseconds or simply because of timezone. =20=

> We recently had a problem with a qualifier over the the daylight=20
> switch date.
>
Yeah, well I'm certain you were not the only one!


> It's a problem when we know (by design) that our view of a date is=20
> limited to the gregorian calendar, i.e. by design we don't care about=20=

> anything else but the calendar date.
> For example on Postgresql, when we have such attribute, we use the=20
> 'date' column type.  On Oracle, we use the equivalent that doesn't=20
> care about time and timezone.
> Even though we correctly set the column type, it's still a problem in=20=

> memory because when we create a NSTimestamp it has the full time=20
> concept, including timezone.  so conversion / equality / qualifier are=20=

> troublesome to maintain and make sure they work across the board.
>
> I'm submitting here an idea that I had for dealing with that.
> Use a custom class on those attribute and not use the default=20
> NSTimestamp.
> I've made a test, created a CustomDate class that internally use 3=20
> integer  (year, month, date) to represent a date.  It's working for=20
> the basics that I have implemented.
> Before I spend too much time completing this class to implement full=20=

> operation on date (add/substract day, months, weeks, etc.), I would=20
> like the general opinion on this design.
>
The trouble might be in getting the SQL to generate properly.


> How do you deal with such problems ?  what development patterns do you=20=

> use ?
>
I thought we had it solved in FrontBase by using the TIMESTAMP WITH=20
TIME ZONE column.  It seemed to work for the longest time.  Then we=20
started to see problems in a few columns.  FrontBase says to not do=20
this and that it will not work.  So far I am using the Delay, Deny, and=20=

Avoid development pattern.   :-P  I guess I will have to get back to=20
this odious task in the next month or so.

Dates.  Shudder.


Chuck


--=20
Practical WebObjects - a book for intermediate WebObjects developers=20
who want to increase their overall knowledge of WebObjects, or those=20
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects