UTC time in millisecond

[Thomas Weidenfeller]

not exactly misconfigure, it's just a choice you make on setup.

No, if System.currentTimeMillis() returns anything else then UTC you
have a broken system. Wether you broke it deliberately, or accidentally
doesn't matter. It is broken.

/Thomas

 

[palmis]

Hi Roman,
I have modify your code:

long lUTCtime = cal.getTime();

with
long lUTCtime = cal.getTime().getTime();
Because it is impossible to cast date to long.

It's correct?

palmis

 

[bhmckendrick]

Ignoring the OS level inconsistencies mentioned in a later post, it's
simply:

Calendar.getInstance(TimeZone.getTimeZone("UTC")).getTime().getTime()

-bhm

 

[palmis]

Hi bhm,
Do you intend to ignoring the solution of Roman with your solution?
It's correct?

Palmis.

 

[P.Hill]

I use the following code:
Calendar cal = Calendar.getInstance();
cal.add(
Calendar.MILLISECOND,
-cal.get(Calendar.DST_OFFSET) -
cal.get(Calendar.ZONE_OFFSET));
long lUTCtime = cal.getTime();
It takes into account summer/winter time transition.

Hi Roman,

Why do you think this is an improvement over
System.currentTimeMillis()?

On what system is this not the result not the same
as new Date()?

I'm really interested to know!

-Paul

 

[P.Hill]

Hi bhm,
Do you intend to ignoring the solution of Roman with your solution?
It's correct?

NO it is NOT.

DateFormat dfUTC = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss.s ZZZ zzz");
dfUTC.setTimeZone(TimeZone.getTimeZone("UTC"));
DateFormat dfLocal = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss.s ZZZ zzz");

Date date1 = new Date();
Calendar cal = Calendar.getInstance();
System.out.println("Short way: " + dfUTC.format(date1));

cal.setTime(date1);
cal.add(Calendar.MILLISECOND, -cal.get(Calendar.DST_OFFSET)
- cal.get(Calendar.ZONE_OFFSET));
Date date2 = cal.getTime();
System.out.println("Long way: " + dfLocal.format(date2));
System.out.println(date1.getTime());
System.out.println(date2.getTime());

Results in setting the hours/min/secs the same but NOT the millisecond time!
Long way: 2006-01-19 04:53:12.12 -0800 PST
Short way: 2006-01-19 04:53:12.12 +0000 UTC
1137647240359
1137676040359



-Paul

 

[Roedy Green]

I use the following code:
Calendar cal = Calendar.getInstance();
cal.add(
Calendar.MILLISECOND,
-cal.get(Calendar.DST_OFFSET) -
cal.get(Calendar.ZONE_OFFSET));
long lUTCtime = cal.getTime();
It takes into account summer/winter time transition.

no it doesn't . The long you get out the end it still is plain old
vanilla UTC. All the Timezone and DST stuff gets thrown away.

you are right back with nothing different from System.timeInMillis,
just some wasted objects.