Don’t forget the milliseconds. A post about dates and Datetime comparison

During my work I find working with date and time objects one of the most challenging things. I just spent a few hours finding out that when you retrieve date from a view column the millisecond part of the date is actually not set at all.

In my current project I’m using a date control to set the date of a certain object. After processing I save this data into notesdocument. I noticed when I switched dates ( using a GregorianCalendar ) and retrieved data from the view the documents didn’t turn up on the screen. After some investigation I found out that when using the date-time control for some reason the date is saved but the milliseconds part of the date is not saved at all. This can lead to some frustation.

Let’s show you a little example

Lets say we have the following code

 

 

At first glance you might think that the lineDate.getTime and the startDate.getTime() would return the same integer if they point to the same date f.i. 31/12/2012 but in fact they wont..

In my particular case. The lineDate.getTime() returned 1356994800000 and startDate.getTime()  returned 1356994800640. As you can see a difference of 640 milliseconds. This is caused by my first call to the GregorianCalendar.getInstance(). It creates a new calendar instance with the date set to the current date /time. So at a specific point in time there are 640 milliseconds at the end.

When you now compare these two methods and use the system.out.println(linedate) directive you will see something like Mon Dec 31 00:00:00 CET 2012 which is the string representation of that date. Which is the same as system.out.println(startDate). But it wont show you the milliseconds! It took me a little while to realize the millisecond part could be different.

If you know this fact you can work around it by adding 1 line to the above example:

 

I hope this blogpost helps someone in the future when working with dates in xPages/Java.