Convert microseconds string to date in Java or Scala

Question

how to convert timestamp(in microseconds) string to date in Java/Scala. My goal is to compare two timestamps and find the differences between them. I'm using java 8 and example Timestamp string is 1474457086337977. I would like to convert this into Date or Timestamp instance.

Answer 1

tl;dr

Instant.EPOCH.plus( 
    Duration.ofNanos( 
        TimeUnit.MICROSECONDS.toNanos( 
            Long.parse( "1474457086337977" ) ) ) )

java.time

The java.time classes support a resolution of nanoseconds, more than enough for your microseconds.

Parsing a string of a number

Parse the string as a long to get a count of microseconds from the epoch.

long micros = Long.parse( "1474457086337977" );

And of course you can always use an integer literal. Note the L appended to integer literal.

long micros = 1_474_457_086_337_977L ;

Converting a long into Instant

We want to transform that count of microseconds from the epoch of beginning of 1970 in UTC (1970-01-01T00:00:00Z) into an Instant. The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds. That means up to nine digits of a decimal fraction.

The Instant class has handy static methods for converting from a count of whole seconds, from a count of whole seconds plus a fractional second in nanoseconds, or from a count of milliseconds. But unfortunately no such methods for a count of microseconds or nanoseconds.

As a workaround, we can define a Duration and add it to the epoch reference date already defined as a constant. We can instantiate a Duration as a number of nanoseconds. To get nanoseconds, we multiply your microseconds by a thousand. Note the use of 64-bit long rather than 32-bit int.

Duration duration = Duration.ofNanos( micros * 1_000L );  
Instant instant = Instant.EPOCH.plus( duration );

instant.toString(): 2016-09-21T11:24:46.337977Z

Alternatively, you can use the TimeUnit enum to convert microseconds to nanoseconds without hard-coding a “magic number”.

Duration duration = Duration.ofNanos( TimeUnit.MICROSECONDS.toNanos( micros ) );  

To adjust into other offsets or time zones, search StackOverflow for Java classes OffsetDateTime or ZonedDateTime.

Converting to legacy date-time types

You should avoid the old date-time types bundled with the earliest versions of Java. They have proven to be poorly-designed, confusing, and troublesome. Now supplanted by the java.time types.

But if you must interact with old code not yet updated to the java.time types, you may convert to/from java.time. Look to new methods added to the old classes.

java.sql.Timestamp ts = java.sql.Timestamp.from( instant );

Beware of data loss when converting from a java.time type to java.util.Date or java.util.Calendar. These types resolve to only milliseconds. A truncation from nanoseconds to milliseconds is performed silently, lopping off those last six (of nine) possible digits of a fractional second.

java.util.Date utilDate = java.util.Date.from( instant );  // Caution: Data loss in truncating nanoseconds to milliseconds.

About java.time

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

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

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

Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport and further adapted to Android in ThreeTenABP (see How to use…).

The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time.

Answer 2

Well, what about converting those microseconds to milliseconds and then just create a timestamp object?

long microsecs = 1474457086337977L;
long millis = TimeUnit.MILLISECONDS.convert(microsecs, TimeUnit.MICROSECONDS);
Timestamp time = new Timestamp(millis);

Wouldn't that work?

--Edit

To address the comments left in the answer:

About Java 8's new Date Time API

First, since you mention that you're using Java 8 I totally agree that a better approach would be to use the new Java 8 Date/Time API. However, this is a luxury you don't always have even when working with Java 8 because you may still be interacting with an old API still using the old Java Date/Time classes, or simply because the rest of your API still uses them and you don't want to start mixing things.

It is not clear in your question if you already know this, you seem to be sure that you want to use either java.util.Date or java.sql.Timestamp and I didn't question that, I just worked around the parameters of your question.

Clearly the new Java date/time APIs are much better than the old ones, but there are millions of lines of code out there still using the old APIs and they work. Yet again I thought that was out of the scope of the answer and it seems you already have other good answers here to address that.

About Possible Data Loss

One comment mentions that the answer might run into data loss. I think in Java all integer arithmetic is subject to potential underflow or overflow. My mistake is probably not have mentioned it.

It is true that TimeUnit.convert method might end up causing overflows or underflows in certain scenarios. It is documented in the method.

• A nanosecond is one billionth of a second (1/1000000000)
• A microsecond is one millionth of a second (1/1000000).
• A millisecond is one thousandth of a second (1/1000)

Which means that, once expressed as a long, a millisecond number should be a much smaller number than a microsecond one, right?

The formula used by TimeUnit.convert is as follows

final long MICROS = 1000000L;
final long MILLIS = 1000L;

long microsecs = 1474457086337977L;
long millisecs = microsecs / (MICROS / MILLIS)

Which means you would run into data loss only if your microseconds are really small numbers e.g. if you had less than 1,000 microseconds. You should validate your code never goes into a scenario like this.

One comment left in this answer argues that the right answer should probably use nanoseconds, but then again a nanosecond long value would be a much bigger number than your microseconds and so, during conversions to nanoseconds you might still run into overflows.

For example, think what would happen if you had Long.MAX_VALUE microseconds, how could you convert that to nanoseconds using just Java long arithmetic without an overflow given that nanoseconds are supposed to be a much bigger number than your Long.MAX_VALUE microseconds?

My point being that regardless of you using Java 8 Date Time or legacy Java Date Time APIs you need a long value representing an instant in the time line, but that long has limitations in regards to how far in the past or how far in the future you can go, and when you do conversions between units, that arithmetic is subject to underflow and overflow and there's no way around it and you should be aware of that to avoid very nasty bugs.

Once more, I thought that was a given and outside the scope of the question and I bring it up only because I got some downvotes for this omission.

Answer 3

You can try following code, which will take time stamp as a string:

 BigInteger b = new BigInteger("1474457086337977");
 b=b.divide(new BigInteger("1000"));

 String x =b.toString();



DateFormat formatter = new SimpleDateFormat("dd/MM/yyyy");

long milliSeconds= Long.parseLong(x);
System.out.println(milliSeconds);

Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(milliSeconds);
System.out.println(formatter.format(calendar.getTime())); 

Or for more accuracy, you can use BigDecimal:

BigDecimal b = new BigDecimal("1474457086337977");
b=b.divide(new BigDecimal("1000"));
String x =b.toString();