CODEWITHSUNDEEP
javadateutc
chlmon99
chlmon99

Reputation: 13

java.util.Date and the UTC problem

I know this has been a hot topic over the time... but I can't find a suitable answer.

I have the current UTC time in ms, which I need to compare to the current time in my machine (so they should match).

long myUTCtime = .....; // This reflects the UTC time
// myDate is in UTC, ok, I agree
Date myDate = new Date();
// When I use getTime() I get the localtime in ms, although not in UTC! but in DST
long milis = myDate.getTime();
// I get here a 60 minute difference
long difference = milis - myUTCtime;

How can I do this?

Thanks in advance.

EDIT: I don't need the calendar or anything. I'm not showing the information to the user, I just want to use UTC times, and Date is supposed to be ALWAYS in UTC

Upvotes: 1

Views: 5630

Answers (6)

Gonzalo Aguilar Delgado
Gonzalo Aguilar Delgado

Reputation: 663

util.Date has nothing to do with TimeZones but I'm not sure of it. Since I have a problem with date in different zones.

  1. My server on UTC takes a date from database stored as timestamp and returns a date of 2015-01-19 13:19:17.0. That is correct since it's what's stored in database. Now I do a .getTime()/1000 of this date and get 421673557.
  2. I do the same from other server with CET date. and date is 2015-01-19 13:19:17.0 (the same) but .getTime()/1000 returns 1421669957.

So this is exactly the difference between UTC and CET time zones. You can do the same by changing your local timezone.

So I think you all are wrong. Or openjdk and oracle sdk have a bug.

Can someone explain, please?

Upvotes: 0

Tomasz Nurkiewicz
Tomasz Nurkiewicz

Reputation: 340733

Date holds the number of milliseconds since 1970, no timezone is involved:

$ date +%s
1305133104
$ groovy -e "println System.currentTimeMillis() / 1000"
1305133106.155
$ groovy -e "println new Date().time / 1000"
1305133107.495

Upvotes: 0

leonbloy
leonbloy

Reputation: 75906

Date myDate = new Date();
long milis = myDate.getTime();

should be equivalent to the simpler:

long milis = System.currentTimeMillis();

Both should return

the difference, measured in milliseconds, between the current time and midnight, January 1, 1970 UTC

Quick check in my linux box:

# cat X.java
public class X { public static void main(String[] args) {
                System.out.println( (new java.util.Date()).getTime());
                System.out.println( System.currentTimeMillis());
        } }

# javac X.java ; java X ; perl -e 'print time()*1000'
1305133124654
1305133124654
1305133124000

Perhaps you have an interpretation issue...

Upvotes: 2

Jason Nichols
Jason Nichols

Reputation: 11733

leonbloy is correct. You don't need to do any offset calculations. Date.getTime() returns the number of milliseconds since the epoch, without regard for your current timezone. This confuses people because Date.toString() returns the date String using your local timezone.

As long as your system time is correct you can do a direct comparison of the long values of your time and the UTC time.

Upvotes: 3

jarnbjo
jarnbjo

Reputation: 34313

I don't know how you populate myUTCtime, but new Date().getTime() or System.currentTimeMillis() returns the number of milliseconds since 1970-01-01 0:00 UTC. If you see a difference to myUTCtime, I would assume that myUTCtime is incorrect. Other possible options is that e.g. your operating system is configured with the wrong time zone, so that the other methods give you incorrect values.

Upvotes: 0

OscarRyz
OscarRyz

Reputation: 199215

Probably using 

Calendar.get(Calendar.ZONE_OFFSET) + Calendar.get(Calendar.DST_OFFSET)) / (60 * 1000)

Would do, as described in this deprecated method:

http://download.oracle.com/javase/6/docs/api/java/util/Date.html#getTimezoneOffset()

See if it works for you.

Upvotes: 0

Related Questions