1

Consider this code:-

        String t = "2013-10-05 09:10:37.029074";
        Timestamp ts = Timestamp.valueOf(t);

        Date d = new Date(ts.getTime());
        Timestamp ts2 = new java.sql.Timestamp(d.getTime());
        System.out.println("ts -->"+ts);
        System.out.println("ts2-->"+ts2);

When I run this, I get the result as.

ts -->2013-10-05 09:10:37.029074           ts2-->2013-10-05 09:10:37.029

I do NOT want to ignore milisecods (Please see the diff between 029074 and 029). It seems to be rounding.

I want to preserve even the fraction.

nav
  • 148
  • 2
  • 5
  • 13
  • If you **must** maintain microsecond precision, is there a specific reason you **must** use `Date`s? – Craig Oct 24 '13 at 22:36
  • look there - i hope it helps http://stackoverflow.com/questions/1712205/current-time-in-microseconds-in-java – YAMM Oct 24 '13 at 22:36
  • What you don't want to ignore(`074`) is actually the microseconds part of time. `029` is the milliseconds part. – fall Apr 06 '21 at 01:25

3 Answers3

5

The Date class only has millisecond precision. It cannot store higher precision.

Javadocs for Date:

The class Date represents a specific instant in time, with millisecond precision.

rgettman
  • 176,041
  • 30
  • 275
  • 357
5

Timestamp has nanosecond precision. Both java.sql.Date and java.util.Date have only millisecond precision. Once you bring either Date into the game, you will lose precision.

So just keep the Timestamp around and grab its milliseconds with getTime to do whatever you need to do but make sure you hold onto it.

Vidya
  • 29,932
  • 7
  • 42
  • 70
4

tl;dr

Both of the troublesome Date & Timestamp classes are now replaced by java.time.Instant.

Instant.now() 
       .toString()

2018-04-04T21:33:37.889228Z

java.time

The Answer by Vidya and by rgettman are both correct, you have run into the limits designed in those classes.

Also, those classes are troublesome, confusing, and flawed. They have been supplanted by the java.time classes. No need to ever use java.util.Date or java.sql.Timestamp again.

The java.util.Date class represents a moment on the timeline in UTC with resolution of milliseconds. That class is now replaced by java.time.Instant, also a moment in UTC, but with a finer resolution of nanoseconds.

Instant instant = Instant.now() ;

In Java 8 specifically, capturing the current moment is limited to milliseconds despite the Instant class being capable of holding nanoseconds. In Java 9 and later, a fresh implementation of Clock allows for capturing the current moment in finer resolution, though limited by the capability of your host OS & hardware. In Oracle JDK 9.0.4 on macOS Sierra, I am seeing microseconds

Instant.now().toString(): 2018-04-04T21:33:37.889228Z

The java.sql.Timestamp class is also replaced by Instant as of JDBC 4.2 and later. You can now directly exchange java.time classes, and forget about the java.sql types.

myPreparedStatement.setObject( … , instant ) ;

…and…

Instant instant = myResultSet.getObject( … , Instant.class ) ;

About java.time

The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.

The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.

To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.

You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.

Where to obtain the java.time classes?

The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154