3

I am trying to convert the below date time string object into a unix epoch timestamp value. However, when i run the program i notice that it generates an epoch value of 1404461110000 which when i check on my ubuntu unix machine is Wed Aug 7 18:06:40 However in reality i am passing July 04 2014-07-04 04:05:10. I have a time zone of America/Toronto on my ubuntu machine but I don't think it should matter here ?

Java code:

            long epoch = 0;
            String str = "2014-07-04 04:05:10";   // UTC

            DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
            Date datenew = df.parse(str);
            epoch = datenew.getTime();

            System.out.println(epoch); // prints 1404461110000

Ubuntu Linux 14.04

date -d@1404461110000

displays= Wed Aug 7 18:06:40 EDT 46475

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
user3846091
  • 1,625
  • 6
  • 24
  • 29

4 Answers4

6

The issue is that you're not dealing with a unix timestamp when calling getTime() in Java. Unix timestamps are expressed in seconds since the epoch, while the values you're getting from Java are milliseconds since the epoch (Jan 01 1970), hence the difference.

It would have to be:

epoch = datenew.getTime() / 1000;

This should get you at least a couple of 10000 years closer. If you still see a difference after that, it's timezone-related, and can be accommodated for by specifying the timezone on your DateFormat instance.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
Robby Cornelissen
  • 91,784
  • 22
  • 134
  • 156
2

java.time

The legacy date-time API (java.util date-time types and their formatting type, SimpleDateFormat etc.) is outdated and error-prone. It is recommended to stop using it completely and switch to java.time, the modern date-time API*.

Solution using java.time, the modern API:

import java.time.Instant;
import java.time.LocalDateTime;
import java.time.ZoneId;
import java.time.ZonedDateTime;
import java.time.format.DateTimeFormatter;
import java.util.Locale;
import java.util.concurrent.TimeUnit;

public class Main {
    public static void main(String[] args) {
        String str = "2014-07-04 04:05:10"; // UTC

        DateTimeFormatter dtf = DateTimeFormatter.ofPattern("u-M-d H:m:s", Locale.ENGLISH);
        LocalDateTime ldt = LocalDateTime.parse(str, dtf);
        ZonedDateTime zdtUtc = ldt.atZone(ZoneId.of("Etc/UTC"));
        Instant instant = zdtUtc.toInstant();
        long epochMillis = instant.toEpochMilli();
        long epochSeconds = TimeUnit.SECONDS.convert(epochMillis, TimeUnit.MILLISECONDS);
        System.out.println(epochSeconds);

        // Corresponding date-time in America/Toronto
        ZonedDateTime zdtToronto = instant.atZone(ZoneId.of("America/Toronto"));
        System.out.println(zdtToronto);
    }
}

Output:

1404446710
2014-07-04T00:05:10-04:00[America/Toronto]

Learn more about java.time, the modern date-time API* from Trail: Date Time.

Some important notes:

  1. Unix time specifies seconds since the Epoch.
  2. We should avoid performing calculations ourselves if there is an OOTB (Out-Of-The-Box) API available for it e.g. TimeUnit#convert.

* For any reason, if you have to stick to Java 6 or Java 7, you can use ThreeTen-Backport which backports most of the java.time functionality to Java 6 & 7. If you are working for an Android project and your Android API level is still not compliant with Java-8, check Java 8+ APIs available through desugaring and How to use ThreeTenABP in Android Project.

Arvind Kumar Avinash
  • 71,965
  • 6
  • 74
  • 110
1

You need to tell Java that the timestamp is UTC, not just add a comment about it.

long epoch = 0;
String str = "2014-07-04 04:05:10";   // UTC

DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
df.setTimeZone(TimeZone.getTimeZone("UTC")); // assume UTC
Date datenew = df.parse(str);
epoch = datenew.getTime();

System.out.println(epoch);
V a a m Y o b
  • 492
  • 3
  • 7
0

Joda-Time

FYI, here is the same kind of code but done in Joda-Time 2.4. The new java.time package in Java 8 (inspired by Joda-Time) could be used in a similar manner.

The java.util.Date and .Calendar classes are notoriously troublesome. Avoid them. Use either of the two libraries mentioned above.

Example Code

Your input string is close to standard ISO 8601 format, but not quite, missing the T in the middle and an offset from UTC. Joda-Time has a built-in formatter for parsing/generating in ISO 8601. So rather than define our own formatter, let's tweak the input String a bit, inserting the T.

String inputRaw = "2014-07-04 04:05:10";   // UTC
String input = inputRaw.replace( " ", "T" ); // Convert to standard ISO 8601 format.

Then we will tell the DateTime constructor to parse the String as being in UTC (zero offset). Unlike java.util.Date, a DateTime knows its own assigned time zone.

DateTime dateTimeUtc = new DateTime( input, DateTimeZone.UTC );

Easy to adjust to Toronto time, for fun or for debugging/sanity-check.

DateTime dateTimeToronto = dateTimeUtc.withZone( DateTimeZone.forID( "America/Toronto" ) );

Like java.util.Date, Joda-Time internally tracks time as a number of milliseconds since the Unix epoch (beginning of 1970) in UTC. That means using a 64-bit long rather than the usual 32-bit int. (By the way, java.time tracks nanoseconds.) So if we need seconds-since-unix-epoch, divide by one thousand.

long millisecondsSinceEpoch = dateTimeUtc.getMillis();  // Use a "long", not "int".
long secondsSinceEpoch = ( millisecondsSinceEpoch / 1000L );

Dump to console.

System.out.println( "input: " + input );
System.out.println( "dateTimeUtc: " + dateTimeUtc );
System.out.println( "dateTimeToronto: " + dateTimeToronto );
System.out.println( "millisecondsSinceEpoch: " + millisecondsSinceEpoch );
System.out.println( "secondsSinceEpoch: " + secondsSinceEpoch );

When run.

input: 2014-07-04T04:05:10
dateTimeUtc: 2014-07-04T04:05:10.000Z
dateTimeToronto: 2014-07-04T00:05:10.000-04:00
millisecondsSinceEpoch: 1404446710000
secondsSinceEpoch: 1404446710
Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154