I am happy! Finally there is some one who is interested in this topic :-) The problem I am highlighting is not about level of accuracy (where you have to bring in Lamport Ordering). Its about a design flaw in the Java API which could lead to a data integrity issues. Here is one example;
For auditing/tracing purposes, a Timestamp is stored in a database. Now when I request an audit trail from some "Audit" service it will have to go to the database retrieve those values and send them as XML. Let's say the service is using JDBC to access the database. JDBC Timestamp extends Java util Date. However, XSD type mapping for Timestamp should be a DateTime and DateTime in Java should be a Calendar. So from the DAO layer it must be instantiating a Calendar instance to send it to the next layer (You have to live with mili second accuracy of course). In the SimpleTypeMapper we use SimpleDateFormat which internally use another Calendar instance (that's the Java implementation). If every thing happens within the same JVM we should be OK unless, we hit the window where the daylight saving change occurs. If we use the original Calendar instance which passed in to SimpleTypeMapper, I think we can avoid this issue. But I guess you get my point. Java's thinking on representing date and time is not comprehensive enough to handle these use cases and that's why we have write code to work around that. As we all know, for many enterprise systems data integrity is very critical. A good design can avoid issues by design, but yet be simple. I can empathize your resistance to inheriting another library. But then discuss how we can accurately represent these design elements. /Sanjaya ----- Original Message ---- From: Eran Chinthaka <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, July 11, 2008 9:43:02 AM Subject: Re: Representing a Birthday in a distributed scenario Hi Sanjaya, I agree with your point here. Also as you might already know, one of the best known ways to represent times within a distributed system is to use an implementation of Lamport clocks. Also these distributed clocks are really useful when the system has large number of nodes. But my question is no one had ever complained about these time problems. And also if we can do this using timezone information (which I am yet to find out), why bother introduce new libraries in to that? We can find loads of things build around, java foundation classes, which claims to improve basic java functionality. If the current thing is working, 99% of the time why bother worrying about it. I can still remember what Sanjiva and Glen wrote on the white board during the last day of first Axis2 summit. We always should KISS and adhere to YAGNI, which I liked a lot. Please note that, I appreciate your suggestion and understand what your point is. But making it a first class citizen by putting those in to ADB, hmm ... I don't think I will agree to that. On Tue, Jul 8, 2008 at 1:47 AM, Sanjaya Karunasena <[EMAIL PROTECTED]> wrote: Hi All, Usually to represent some thing like a Birthday java Date class is used. However, it internally make use of a Calendar instance in most of the operations. This means unless we send timezone information in a Web Service request with the birthday, there is a time window, when the client and the server is in two different timezones, the day get represented inaccurately. I came across this library (http://joda-time.sourceforge.net) which doesn't suffer from such design flaws. (http://joda-time.sourceforge.net/key_partial.html) Thoughts? Probably we need to fix ADB to handle this. /Sanjaya -- With Mettha, Eran Chinthaka -------------------------------------------------------------------- Health is the greatest gift; contentment is the greatest wealth; trusting is the best relationship; nirvana is the highest joy. - Dhammapada
