Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > System.currentTimeMillis()

Reply
Thread Tools

System.currentTimeMillis()

 
 
Shin
Guest
Posts: n/a
 
      08-03-2005
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)

 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      08-03-2005
On 3 Aug 2005 09:46:54 -0700, "Jerry" <(E-Mail Removed)> wrote
or quoted :

>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/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes
 
Reply With Quote
 
 
 
 
Pete Barrett
Guest
Posts: n/a
 
      08-04-2005
On 3 Aug 2005 10:56:30 -0700, "Jerry" <(E-Mail Removed)> wrote:

>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
 
Reply With Quote
 
Thomas Hawtin
Guest
Posts: n/a
 
      08-04-2005
Pete Barrett wrote:
>
> 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
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
 
Reply With Quote
 
Jerry
Guest
Posts: n/a
 
      08-04-2005
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!


Thomas Hawtin wrote:
> Pete Barrett wrote:
> >
> > 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
> --
> Unemployed English Java programmer
> http://jroller.com/page/tackline/


 
Reply With Quote
 
Brooks Hagenow
Guest
Posts: n/a
 
      08-05-2005
Jerry wrote:
> 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!!!
 
Reply With Quote
 
Nigel Wade
Guest
Posts: n/a
 
      08-05-2005
Thomas Hawtin wrote:

> Pete Barrett wrote:
>>
>> 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>.


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.

--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : http://www.velocityreviews.com/forums/(E-Mail Removed)
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
 
Reply With Quote
 
Thomas Hawtin
Guest
Posts: n/a
 
      08-05-2005
Nigel Wade wrote:
> Thomas Hawtin wrote:
>
>
>>Pete Barrett wrote:
>>
>>>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>.

>
>
> 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
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
 
Reply With Quote
 
Thomas G. Marshall
Guest
Posts: n/a
 
      08-06-2005
Jerry coughed up:
>
> Harry Bosch wrote:
>> Jerry wrote:
>>> 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/...entTimeMillis()
>>
>> "returns the difference, measured in milliseconds, between the
>> current time and midnight, January 1, 1970 UTC"

>
> 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.



--
Forgetthesong,I'dratherhavethefrontallobotomy...


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments