System.currentTimeMillis()

Discussion in 'Java' started by Jerry, Aug 3, 2005.

  1. Jerry

    Jerry Guest

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

    Thanks a lot!
     
    Jerry, Aug 3, 2005
    #1
    1. Advertising

  2. On 3 Aug 2005 09:46:54 -0700, Jerry wrote:

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


    Test it, report back.

    --
    Andrew Thompson
    physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
    Bender's Humor By 'Microsoft Joke'
     
    Andrew Thompson, Aug 3, 2005
    #2
    1. Advertising

  3. Jerry

    Harry Bosch Guest

    Harry Bosch, Aug 3, 2005
    #3
  4. Jerry wrote:
    > 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
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, Aug 3, 2005
    #4
  5. 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!
    >


    Did you read the documentation for the method?

    Ray

    --
    XML is the programmer's duct tape.
     
    Raymond DeCampo, Aug 3, 2005
    #5
  6. Jerry

    Jerry Guest

    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!



    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/api/java/lang/System.html#currentTimeMillis()
    >
    > "returns the difference, measured in milliseconds, between the current
    > time and midnight, January 1, 1970 UTC"
     
    Jerry, Aug 3, 2005
    #6
  7. Jerry

    Jerry Guest

    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!
     
    Jerry, Aug 3, 2005
    #7
  8. Jerry

    Pete Barrett Guest

    On 3 Aug 2005 09:46:54 -0700, "Jerry" <> wrote:

    >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
     
    Pete Barrett, Aug 3, 2005
    #8
  9. Jerry wrote:
    > 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.

    --
    "Thomas:Fritsch$ops:de".replace(':','.').replace('$','@')
     
    Thomas Fritsch, Aug 3, 2005
    #9
  10. Jerry

    Jerry Guest

    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?
     
    Jerry, Aug 3, 2005
    #10
  11. Jerry

    Shin Guest

    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)
     
    Shin, Aug 3, 2005
    #11
  12. Jerry

    Roedy Green Guest

    On 3 Aug 2005 09:46:54 -0700, "Jerry" <> 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/mckinney_grills_rumsfeld.htm

    Canadian Mind Products, Roedy Green.
    See http://mindprod.com/iraq.html photos of Bush's war crimes
     
    Roedy Green, Aug 4, 2005
    #12
  13. Jerry

    Pete Barrett Guest

    On 3 Aug 2005 10:56:30 -0700, "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?


    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
     
    Pete Barrett, Aug 4, 2005
    #13
  14. 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/
     
    Thomas Hawtin, Aug 4, 2005
    #14
  15. Jerry

    Jerry Guest

    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/
     
    Jerry, Aug 5, 2005
    #15
  16. 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!!! :)
     
    Brooks Hagenow, Aug 5, 2005
    #16
  17. Jerry

    Nigel Wade Guest

    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 :
    Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
     
    Nigel Wade, Aug 5, 2005
    #17
  18. 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/
     
    Thomas Hawtin, Aug 5, 2005
    #18
  19. 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/api/java/lang/System.html#currentTimeMillis()
    >>
    >> "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...
     
    Thomas G. Marshall, Aug 6, 2005
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nelson
    Replies:
    17
    Views:
    9,186
    Darryl L. Pierce
    May 20, 2004
  2. Alex
    Replies:
    15
    Views:
    2,718
  3. Roedy Green
    Replies:
    8
    Views:
    1,184
    Daniel Dyer
    Mar 9, 2006
  4. neoedmund
    Replies:
    1
    Views:
    1,185
  5. tak
    Replies:
    6
    Views:
    2,383
    James Kanze
    Sep 28, 2007
Loading...

Share This Page