Scaled or Granular Dates

first, apologies if this is to the wrong newsgroup, but I couldn't think of anywhere beter to post the query. If anyone has any ideas as where to send this, I'd appreciate it.

I come from a Java background and I have continually found that working with dates is a frustrating experience, and recently it dawned on my as to why. All Dates in Java, and I believe in most all areas of computing are measured as distinct points in time to some predefined granularity. In Java the granularity is a millisecond. This is fine when you wish to record a specific time down to the nearest millisecond, but as soon as you decide that you only need to store to the nearest minute or day, the programmer has to record in comments or documentation that the extra accuracy of the timestamp is to be ignored. The predominant system doesn't allow you to store within the date itself the granularity being used.

For instance I would like to store this information as single date objects; 14:30, 1st January, 1970
1st January 1970
January 1970
1970
1970s
1900s
1st millenium AD

Now I can currently store the first four dates with the current system, although I would have to record the granularity they were gathered at in a different place. The last three dates are impossible to store (well, I might store the 1970s at a push, but since Dates in Java are stored as milliseconds since 1970, I think I'm pushing the limits of the format in doing this).

Somebody might say, that the latter dates are really periods that should be recorded as two dates: They are periods but then again, aren't all date/times. There is no way of recording an instant in time as there is always a higher level of accuracy that exists, but cannot be measured. This is where scale comes into play. The scales of the above examples are; minutes
days
months
years
decades
centuries
millenia

An advantage that I can see very clearly as an application developer is that simply from the information stored within a scaled date type, I can dynamically decide what sort of UI component should display the field. For instance a date stored at month granularity would only require an MM/YYYY input field, whereas one that stored the day as well, would display to day accuracy. Furthermore, users of a system can decide themselves what accuracy there is in a date that they provide. I know that my grandfather was born in 1911, but his grandfather I might only be able to place to the nearest decade.

So hopefully I've explained my requirements, can someone please answer these questions?

1. Is this old ground that has been covered before, written about in many theses, and thrown away as a bad idea? If so, can anyone point me to any reading on this subject.
2. I would like to create my own Java object to handle granular dates as I describe above. What would be the best way to make them persist in a database? Should I just use a long integer with a special format to denote the value and scale? Any recommendations?
3. Does anyone have any feedback on this; problems inherent with the idea, whatever. Any feedback is very welcome.

Looking forward to your response.
Pat Turner Received on Wed Jan 07 2004 - 14:42:43 CET