Calendar precision

Question

Is there a way to get something like a Calendar that may be more precise?
If I do this:
java.util.Calendar c1 = java.util.Calendar.getInstance();
java.util.Calendar c2 = java.util.Calendar.getInstance();
java.util.Calendar c3 = java.util.Calendar.getInstance();
java.util.Calendar c4 = java.util.Calendar.getInstance();
System.out.println(c1.getTimeInMillis());
System.out.println(c2.getTimeInMillis());
System.out.println(c3.getTimeInMillis());
System.out.println(c4.getTimeInMillis());I'll get repeated lines. And c2 will equal c1 or c3.
I'd like to be able to put some objects in a HashMap using the time they go in as the key. I know I can only put one Object in at a time (and I'm not even threading anything), so I had assumed that would be a unique enough key. I was using Gregorian Calendars as keys. In testing, though, things went fast enough that I got Equal calendars - which meant equal keys, which meant some objects didn't stay in the Map. That's bad.
I'm working around this now by sleeping for a millisecond after adding an object. But that feels really, really stupid.
Any suggestions are very much appreciated.
Thanks,
Scott

Answer 1

The goal is to be able to get Objects from the
collection based on when they went in. If you can
access objects by date, you can get a bunch of the
objects from a range, or a state at any given time.Why would that have anything to do with creating a
unique key for a hashmap?The TemporalCollection class i was writing uses a HashMap. That's why. HashMap keys have to be unique in order to not overwrite older objects.
Generally you use a key in a hashmap so you can put
other items in and get items out.Right. Use the key to find objects.
Unless you keep track of this value you will never be
able to do that.Right. The Map keeps track of its keys.
And what happens if someone does put two items in at
the same time? Although technically that can't happen
from a computing standpoint it most definitely can
happen from a business standpoint. For example if
someone is moving out of one place they might very
well be moving into another place at the very "same"
time. Or when transfering money from one account to
another.If you're moving, there is no reason to track into and out of each address. You just track intos and assume that the person lives there until they move into some other place. One date per move instead of two dates per house that would have to be synchronized (like for correcting an input error).
When transfering money between accounts, you have two accounts. They each have their own TemporalCollection list/map.
And I doubt any business user (that deals with people
"moving") cares about millisecond precision. They
probably don't even care about second precision. And
it is even possible all they want is day precision.My goal is to write a class that handles as many situations as possible. The business use I was writing for would need minutes of precision at best. But in writing a test for the class, objects were flying faster than milliseconds were incremented. It would suck to tell a client that their computer is too fast for your program. Hence my original question. It's not a matter of wanting to know the millisecond that something happened, it's wanting to know what happened first.
There's obviously more than one way to accomplish this. DrClap suggested using a list and a containing object instead of a map. That solution sould have no problems with duplicate times (as long as the business use doesn't).
A map is just one way to do it. It's the way I started with based on what I was reading. It may not be perfect. Any attempt to order things by time needs a way of marking time thats as precise as the differences in time might be. If the computer can just do milliseconds, and it's possible that things could happen faster than that, you need some workaround. That's what happened. That's why I wrote. That's what I got help with.
If you're still curious about what I'm trying to do (or why in hell I'm trying) check out the martinfowler link a few posts above. It gives a summary of the problem and some code that I started with.
I know a lot of people post with really stupid questions about things they haven't thought out very well. I don't think this is one of them :) but I appreciate the challenges to my assumptions.
-s