System.currentTimeMillis()

[Jerry]

System.currentTimeMillis() retuns current UTC time in MilliSeconds or a
time that depends on the current OS and time zone?

Thanks a lot!

 

[Andrew Thompson]

System.currentTimeMillis() retuns current UTC time in MilliSeconds or a
time that depends on the current OS and time zone?

Test it, report back.

 

[Harry Bosch]

System.currentTimeMillis() retuns current UTC time in MilliSeconds or a
time that depends on the current OS and time zone?

Thanks a lot!

Right here in the JavaDoc:

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html#currentTimeMillis()

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

 

[Thomas Hawtin]

System.currentTimeMillis() retuns current UTC time in MilliSeconds or a
time that depends on the current OS and time zone?

"Returns:
"the difference, measured in milliseconds, between the current time
and midnight, January 1, 1970 UTC."

So what do you think?

Having said people often have incorrectly set time zones and spin UTC
around themselves. And PCs apparently having the BIOS time time zone
dependent (and not specified) doesn't help.

I also find on my machine (RedHat 9), nanoTime goes backwards with the
system clock, which it shouldn't.

Tom Hawtin

 

[Raymond DeCampo]

System.currentTimeMillis() retuns current UTC time in MilliSeconds or a
time that depends on the current OS and time zone?

Thanks a lot!

Did you read the documentation for the method?

Ray

 

[Jerry]

The Java Doc says: "Returns the current time in milliseconds. Note that
while the unit of time of the return value is a millisecond, the
granularity of the value depends on the underlying operating system and
may be larger."

Does this mean that System.currentTimeMillis() return the teime that
depends on the current OS and time zone?

Thanks a lot!

 

[Jerry]

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

The current time means the current UTC time in Milliseconds or the
current OS and Timezone time in Milliseconds?

Thanks!

 

[Pete Barrett]

System.currentTimeMillis() retuns current UTC time in MilliSeconds or a
time that depends on the current OS and time zone?

It returns the number of milliseconds since the epoch (which is
midnight Jan 1st 1970 UTC. (This is in the JavaDocs.)

Or, to put it another way, Java seems to consider local time and UTC
to be different presentations of the same time, not different times.
It goes all the way through Java, so you'd better learn to think in
that way!

Pete Barrett

 

[Thomas Fritsch]

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

The current time means the current UTC time in Milliseconds or the
current OS and Timezone time in Milliseconds?

Thanks!

"Current time" simply means: "now", "at this moment".
This definition is complete by itself. There is no reference to any OS
or timezone needed to make the definition complete.
Remember: time did already exist before computers or time-zones were
invented.

 

[Jerry]

It returns the number of milliseconds since the epoch (which is
midnight Jan 1st 1970 UTC.

The current time means the current UTC time in Milliseconds or the
current OS and Timezone time in Milliseconds?

 

[Shin]

the substraction of current time and epoch will always be the same, no
matter how you represent current time (you have to represent epoch the
same way)

 

[Roedy Green]

System.currentTimeMillis() retuns current UTC time in MilliSeconds or a
time that depends on the current OS and time zone?

see http://mindprod.com/jgloss/time.html

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Pete Barrett]

It returns the number of milliseconds since the epoch (which is
midnight Jan 1st 1970 UTC.

The current time means the current UTC time in Milliseconds or the
current OS and Timezone time in Milliseconds?

If you think about it, you'll see that the number of milliseconds
between <Now> and <Midnight Jan 1st 1970 UTC> is constant, no matter
what time zone you *represent* time in. As I said, make clear to
yourself the distinction between time and its representation.

Pete Barrett

 

[Thomas Hawtin]

If you think about it, you'll see that the number of milliseconds
between <Now> and <Midnight Jan 1st 1970 UTC> is constant, no matter
what time zone you *represent* time in. As I said, make clear to
yourself the distinction between time and its representation.

Not really. I'm here in the WET. Because of daylight savings the
difference between 4/8/2004 7:45:37 PM WET and <Midnight Jan 1st 1970
WET> is an hour different than 4/8/2004 7:45:37 PM UTC and <Midnight Jan
1st 1970 UTC>.

Not that I think the documentation unclear.

Tom Hawtin

 

[Jerry]

I did some testing by changing the time zone of my computer. Pete is
right, System.currentTimeMillis() returns constant difference no matter
what the time zone is. It always return the current GMT time and
Midnight GMT 01/01/1970.

Thank you all for your answers!

 

[Brooks Hagenow]

It returns the number of milliseconds since the epoch (which is
midnight Jan 1st 1970 UTC.

The current time means the current UTC time in Milliseconds or the
current OS and Timezone time in Milliseconds?

The answer is "yes" and the javadoc explains that.

The number of milliseconds between epoch and now is the same no matter
what time zone or OS you are using.

The point of reference (epoch) is midnight, January 1st, 1970. The
getTimeInMillis() and setTimeInMillis(long) methods of
java.util.Calendar, java.util.Date, etc. are all returning or looking
for the number of milliseconds from epoch. It does not matter what
timezone you are in because the point of reference (epoch) is always the
same.

Timezone is only an offset to display the current time as understood by
those at a location.

I for one wouldn't mind seeing the elimination of time zones. Who
decided noon has to be the middle of the day? If I am working with
someone in California and I am in Wisconsin and we want to have a
conference call at three o'clock, why must it be asked which three
o'clock we mean? That is what doesn't make sense to me.

DOWN WITH TIMEZONES!!!

 

[Nigel Wade]

Not really. I'm here in the WET. Because of daylight savings the
difference between 4/8/2004 7:45:37 PM WET and <Midnight Jan 1st 1970
WET> is an hour different than 4/8/2004 7:45:37 PM UTC and <Midnight Jan
1st 1970 UTC>.

Now is now, no matter what timezone you might represent now in; it's a
single instant in time. Therefore it's fixed in relation the entire world.
The time 00:00 Jan 1st 1970 UTC is also a single instant in time. Therefore
the difference between the two is also fixed. You need to think about it
for a little longer.

Your example is considering two different "now"s, which are 1 hour apart.
You need to consider the same *now* to get the same result.

 

[Thomas Hawtin]

Thomas Hawtin wrote:




Now is now, no matter what timezone you might represent now in; it's a
single instant in time. Therefore it's fixed in relation the entire world.
The time 00:00 Jan 1st 1970 UTC is also a single instant in time. Therefore
the difference between the two is also fixed. You need to think about it
for a little longer.

Your example is considering two different "now"s, which are 1 hour apart.
You need to consider the same *now* to get the same result.

Sorry I misread your point. I assumed the original poster was confused
because he didn't know what timezone was used including for the epoch
start. For instance if I'm in BST, time since 00:00 Jan 1st 1970 BST is
going to be one hour out from time since 00:00 Jan 1st 1970 UTC.

Tom Hawtin

 

[Thomas G. Marshall]

Jerry coughed up:

The Java Doc says: "Returns the current time in milliseconds. Note
that while the unit of time of the return value is a millisecond, the
granularity of the value depends on the underlying operating system
and may be larger."

Does this mean that System.currentTimeMillis() return the teime that
depends on the current OS and time zone?

No, and you're getting confused beyond belief. All it means is that the
underlying system might only be able to count in multiples of, say, 1/60th
of a second. Regardless of this, however, the count will be in
milliseconds.

Think of it this way, pretend that the system goes in multiples of 1/100th
of a second. The millisecond values returned would never be closer than 10
apart from each other.