Consideration for Date management

Summary :

How do efficiently deal with gregorian date, when we absolutely (by 
design) do not care about time issue ?
How about :
In EOModeler, use a custom class (custom data type) to represent 
gregorian calendar attribute, to avoid dealing with time, timezone and 
daylight saving.  This custom class (name it GCDate, for 
GregorianCalendarDate) would not care at all about time issue, and 
would be able to calculate dates.

What do you think about this ?
It it worth the trouble ?
Is it something you tried but couldn't get it to work correctly because 
of ... ?
Is it something you have successfully implemented ?

Long :

We frequently have to deal with date (year/month/day) using nstimestamp 
(year/month/day/hour/minutes/secons/milliseconds/timezone), thus we 
always deal with object being on the same date, but not being equals 
because of differences in milliseconds or simply because of timezone.  
We recently had a problem with a qualifier over the the daylight switch 
date.
It's a problem when we know (by design) that our view of a date is 
limited to the gregorian calendar, i.e. by design we don't care about 
anything else but the calendar date.
For example on Postgresql, when we have such attribute, we use the 
'date' column type.  On Oracle, we use the equivalent that doesn't care 
about time and timezone.
Even though we correctly set the column type, it's still a problem in 
memory because when we create a NSTimestamp it has the full time 
concept, including timezone.  so conversion / equality / qualifier are 
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 
NSTimestamp.
I've made a test, created a CustomDate class that internally use 3 
integer  (year, month, date) to represent a date.  It's working for the 
basics that I have implemented.
Before I spend too much time completing this class to implement full 
operation on date (add/substract day, months, weeks, etc.), I would 
like the general opinion on this design.

How do you deal with such problems ?  what development patterns do you 
use ?

thanks,

- jfv