System.currentTimeMillis not returning GMT/UTC (J2me)

Discussion in 'Java' started by Nelson, May 13, 2004.

  1. Nelson

    Nelson Guest

    I've got an application that I built for the Motorola i730
    MIDP2.0 platform. System.currentTimeMillis() always seems
    to return me -as stated- in GMT/UTC. I ported the application
    to run against the i88s phone MIDP1.0 and the same method
    is returning me the time in the Local Time.
    Is this a know issue, or am I going about this the wrong
    way? It would be so bad getting the local time, but it appears
    that TimeZone.getDefault().getID() is returning GMT !
    Any ideas?
    Thanks.
     
    Nelson, May 13, 2004
    #1
    1. Advertising

  2. Nelson

    P.Hill Guest

    Nelson wrote:
    > I've got an application that I built for the Motorola i730
    > MIDP2.0 platform. System.currentTimeMillis() always seems
    > to return me -as stated- in GMT/UTC. I ported the application
    > to run against the i88s phone MIDP1.0 and the same method
    > is returning me the time in the Local Time.


    So how do you know that the currentTimeMillis is local time?
    I don't know about you, but I wouldn't recognize milliseconds since 1970
    if it bit me, so I'm guess you are doing something with it and
    that processing is picking up a TZ from somewhere.
    Are you using a SimpleDateFormat object to create a formatted data/time?
    Could you show us example code.

    -Paul
     
    P.Hill, May 13, 2004
    #2
    1. Advertising

  3. (Nelson) wrote in message news:<>...
    > I've got an application that I built for the Motorola i730
    > MIDP2.0 platform. System.currentTimeMillis() always seems
    > to return me -as stated- in GMT/UTC. I ported the application
    > to run against the i88s phone MIDP1.0 and the same method
    > is returning me the time in the Local Time.
    > Is this a know issue, or am I going about this the wrong
    > way? It would be so bad getting the local time, but it appears
    > that TimeZone.getDefault().getID() is returning GMT !
    > Any ideas?
    > Thanks.


    Maybe the simplest solution is, appove an adjustment of the
    application or system model to fit an additional machineTypeId
    configuration parameter,
    preform an application boot check,
    maw
     
    Mark A. Washburn, May 14, 2004
    #3
  4. Nelson

    Chris Smith Guest

    Nelson wrote:
    > I've got an application that I built for the Motorola i730
    > MIDP2.0 platform. System.currentTimeMillis() always seems
    > to return me -as stated- in GMT/UTC. I ported the application
    > to run against the i88s phone MIDP1.0 and the same method
    > is returning me the time in the Local Time.
    > Is this a know issue, or am I going about this the wrong
    > way? It would be so bad getting the local time, but it appears
    > that TimeZone.getDefault().getID() is returning GMT !


    Sounds like the device thinks it's in GMT. Since the device doesn't
    know its time zone, it would then be absolutely impossible to get that
    information from anywhere else, unless you're connected to some remote
    device that might know.

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, May 14, 2004
    #4
  5. Nelson wrote:

    > I've got an application that I built for the Motorola i730
    > MIDP2.0 platform. System.currentTimeMillis() always seems
    > to return me -as stated- in GMT/UTC. I ported the application
    > to run against the i88s phone MIDP1.0 and the same method
    > is returning me the time in the Local Time.
    > Is this a know issue, or am I going about this the wrong
    > way? It would be so bad getting the local time, but it appears
    > that TimeZone.getDefault().getID() is returning GMT !


    If the device isn't aware of its timezone, then there's no way for you to
    determine from within the device that same information. Have you checked to
    make sure that you i730's operating system is configured with the right
    timezone? What is the difference between what your MIDlet thinks the time
    is and what the phone states the time is from the main screen?

    Also, have you checked what the java.util.Date class claims the local
    date/time is when you create an instance using new Date()? Forget what
    System.currentTimeMillis() returns if you can get the proper information
    from Date.

    --
    /**
    * @author Darryl L. Pierce <>
    * @see The J2ME FAQ <http://mypage.org/mcpierce/j2mefaq.html>
    * @quote "What do you care what others think, Mr. Feynman?"
    * @geek echo '$_ = "Jvtu bopuifs Pfsm ibdlfs."; y/a-z/za-y/; print' |
    perl
    */
     
    Darryl L. Pierce, May 15, 2004
    #5
  6. P.Hill wrote:

    >> I've got an application that I built for the Motorola i730
    >> MIDP2.0 platform. System.currentTimeMillis() always seems
    >> to return me -as stated- in GMT/UTC. I ported the application
    >> to run against the i88s phone MIDP1.0 and the same method
    >> is returning me the time in the Local Time.

    >
    > So how do you know that the currentTimeMillis is local time?
    > I don't know about you, but I wouldn't recognize milliseconds since 1970
    > if it bit me, so I'm guess you are doing something with it and
    > that processing is picking up a TZ from somewhere.
    > Are you using a SimpleDateFormat object to create a formatted data/time?
    > Could you show us example code.


    The MIDP doesn't have SimpleDateFormat.

    --
    /**
    * @author Darryl L. Pierce <>
    * @see The J2ME FAQ <http://mypage.org/mcpierce/j2mefaq.html>
    * @quote "What do you care what others think, Mr. Feynman?"
    * @geek echo '$_ = "Jvtu bopuifs Pfsm ibdlfs."; y/a-z/za-y/; print' |
    perl
    */
     
    Darryl L. Pierce, May 15, 2004
    #6
  7. Nelson

    P.Hill Guest

    Darryl L. Pierce wrote:
    > The MIDP doesn't have SimpleDateFormat.


    Hm, curious. That begs the questions of how the OP knew
    what the time was that he had. I assume there is some
    similar class.

    -Paul
     
    P.Hill, May 16, 2004
    #7
  8. Nelson

    P.Hill Guest

    Darryl L. Pierce wrote:

    > Also, have you checked what the java.util.Date class claims the local
    > date/time is when you create an instance using new Date()? Forget what
    > System.currentTimeMillis() returns if you can get the proper information
    > from Date.


    The value of the two are exactly the same on a full size JDK. The Date
    constructor gets its time from currentTimeMillis.

    -Paul
     
    P.Hill, May 16, 2004
    #8
  9. P.Hill wrote:

    >> Also, have you checked what the java.util.Date class claims the local
    >> date/time is when you create an instance using new Date()? Forget what
    >> System.currentTimeMillis() returns if you can get the proper information
    >> from Date.

    >
    > The value of the two are exactly the same on a full size JDK. The Date
    > constructor gets its time from currentTimeMillis.


    The Javadoc for System.currentTimeMillis() states that it returns
    "the specified number of milliseconds since the standard base time
    known as 'the epoch', namely January 1, 1970, 00:00:00 GMT." One should
    not be expecting System.currentTimeMillis() to return the _local_ time.
    The Date constructor takes the current time from System.currentTimeMillis()
    and then uses your timezone to convert that value to the local time.
    So, it's inaccurate to claim that System.currentTimeMillis() and Date
    return the same value unless your locale *is* GMT.

    --
    /**
    * @author Darryl L. Pierce <>
    * @see The J2ME FAQ <http://mypage.org/mcpierce/j2mefaq.html>
    * @quote "What do you care what others think, Mr. Feynman?"
    * @geek echo '$_ = "Jvtu bopuifs Pfsm ibdlfs."; y/a-z/za-y/; print' |
    perl
    */
     
    Darryl L. Pierce, May 17, 2004
    #9
  10. P.Hill wrote:

    > Darryl L. Pierce wrote:
    >> The MIDP doesn't have SimpleDateFormat.

    >
    > Hm, curious. That begs the questions of how the OP knew
    > what the time was that he had. I assume there is some
    > similar class.


    You have java.util.Date available, with the default constructor creating a
    Date object with the current date/time.

    --
    /**
    * @author Darryl L. Pierce <>
    * @see The J2ME FAQ <http://mypage.org/mcpierce/j2mefaq.html>
    * @quote "What do you care what others think, Mr. Feynman?"
    * @geek echo '$_ = "Jvtu bopuifs Pfsm ibdlfs."; y/a-z/za-y/; print' |
    perl
    */
     
    Darryl L. Pierce, May 17, 2004
    #10
  11. Nelson

    P.Hill Guest

    Darryl L. Pierce wrote:
    > The Javadoc for System.currentTimeMillis() states that it returns
    > "the specified number of milliseconds since the standard base time
    > known as 'the epoch', namely January 1, 1970, 00:00:00 GMT." One should
    > not be expecting System.currentTimeMillis() to return the _local_ time.
    > The Date constructor takes the current time from System.currentTimeMillis()
    > and then uses your timezone to convert that value to the local time.
    > So, it's inaccurate to claim that System.currentTimeMillis() and Date
    > return the same value unless your locale *is* GMT.


    Say what?

    " Although the Date class is intended to reflect coordinated universal time
    (UTC), ..."

    Notice also that all constructors but
    public Date(long date) are deprecated. Why? Exactly for the reason the
    OP was having trouble. There would have to be an implicit TZ lookup and
    calculation happening.

    Check the source. You'll find that internally a Date is represented as
    a GMT/UTC millisecond value.

    In fact here is the source for the no arg c'tor:

    public Date() {
    this(System.currentTimeMillis());
    }

    Darryl L. Pierce wrote:
    > P.Hill wrote:
    >> That begs the questions of how the OP knew
    >>what the time was that he had.

    >
    > You have java.util.Date available, with the default constructor creating a
    > Date object with the current date/time.


    You are still missing my point. A java.util.Date contains a large binary
    number, something else formats it into a String; that includes doing the
    most simple:
    Date a = new Date()
    System.out.println( a.toString() );

    So if the OP used that or anything else to get a string, I wonder what TZ
    his method of choice used on J2ME to convert from the internal binary
    representation to the a readable string. It is in this conversion that the
    problem lies.

    Consider also the code for comparing two date (and time) objects; if a
    Date object was TZ dependant, a simple equals() or compare() would have to
    normalize to compare, this is not what you want for simple date comparisons.

    I hope that helps to clarify that in a Date() object these is a GMT value
    based on binary GMT time value and that the TZ comes in when making a String not
    when pushing around binary Date values.

    -Paul
     
    P.Hill, May 17, 2004
    #11
  12. P.Hill wrote:

    > Darryl L. Pierce wrote:
    >> The Javadoc for System.currentTimeMillis() states that it returns
    >> "the specified number of milliseconds since the standard base time
    >> known as 'the epoch', namely January 1, 1970, 00:00:00 GMT." One should
    >> not be expecting System.currentTimeMillis() to return the _local_ time.
    >> The Date constructor takes the current time from
    >> System.currentTimeMillis() and then uses your timezone to convert that
    >> value to the local time. So, it's inaccurate to claim that
    >> System.currentTimeMillis() and Date return the same value unless your
    >> locale *is* GMT.

    >
    > Say what?


    I said that System.currentTimeMillis() is *not* returning *local* time, and
    you can only say it *does* if your current locale is *GMT*. I also said
    that the Date constructor takes the value returned by
    System.currentTimeMillis() but does not return *that* as the local date
    either, but instead uses other information to convert that value into the
    local time when the local time is requested.

    > " Although the Date class is intended to reflect coordinated universal
    > time (UTC), ..."
    >
    > Notice also that all constructors but
    > public Date(long date) are deprecated. Why? Exactly for the reason the
    > OP was having trouble. There would have to be an implicit TZ lookup and
    > calculation happening.


    So they do the conversion internally. Where did I say otherwise? I said
    before that Date "uses your timezone to convert [the value from
    System.currentTimeMillis()] to the local time". Why are you on about the
    deprecated constructors?

    > Check the source. You'll find that internally a Date is represented as
    > a GMT/UTC millisecond value.


    Yeah, so? When did I say otherwise? I said that the value *RETURNED* by Date
    was the local time. I never said it didn't hold the date internally as the
    local date/time.

    > In fact here is the source for the no arg c'tor:
    >
    > public Date() {
    > this(System.currentTimeMillis());
    > }


    So? I never said it didn't use the value, and *did* say explicitly that Date
    *does* get its value from System.currentTimeMillis(). What's your point in
    arguing with me?

    <snip>

    > I hope that helps to clarify that in a Date() object these is a GMT value
    > based on binary GMT time value and that the TZ comes in when making a
    > String not when pushing around binary Date values.


    You clarify something that wasn't in question. Nobody said that Date held
    the local date/time...

    --
    /**
    * @author Darryl L. Pierce <>
    * @see The J2ME FAQ <http://mypage.org/mcpierce/j2mefaq.html>
    * @quote "What do you care what others think, Mr. Feynman?"
    * @geek echo '$_ = "Jvtu bopuifs Pfsm ibdlfs."; y/a-z/za-y/; print' |
    perl
    */
     
    Darryl L. Pierce, May 18, 2004
    #12
  13. Nelson

    P.Hill Guest

    Darryl L. Pierce wrote:
    > I said that System.currentTimeMillis() is *not* returning *local* time, and
    > you can only say it *does* if your current locale is *GMT*.


    Sorry, we are in agreement here. currentTimeMillis() returns GMT.
    I was not in any way trying to suggest, and don't see where I suggested,
    that currentTimeMillis() is possibly a local time at any place in this
    thread. If I did claim the currentTimeMillis() *might* return a local
    time then I'd have to make a statement about conversion to the
    internal format or claim that internally the value could be either
    local or GMT. Reading my post I think you'll agree I was assuming
    Date kept one consistent representation -- "GMT".

    > I also said
    > that the Date constructor takes the value returned by
    > System.currentTimeMillis() but does not return *that* as the local date
    > either, but instead uses other information to convert that value into the
    > local time when the local time is requested.


    But this is where the confusion starts. Constructors don't return anything.
    And in the case of java.util.Date() the constructor doesn't do any conversion.
    The result of a constructor is an object which interally has a GMT value.
    When the time is requested, there IS NO CONVERSION unless a readable
    string representation is requested then, and only then, is there a conversion.

    > So they do the conversion internally. Where did I say otherwise?


    With your use of the word constructor in both your last message and
    in your penultimate message you suggest that on its way IN the value
    might be converted in some way.

    > I said
    > before that Date "uses your timezone to convert [the value from
    > System.currentTimeMillis()] to the local time".


    Only the toString() method through the use of a SimpleDateFormat
    does any TZ aware conversion. Now in the ME edition it uses a slight
    different approach, but it still converts in the toString() method.

    > Why are you on about the
    > deprecated constructors?


    I thought it would help to illustrate that Date does NOT store
    a timezone aware value. Apparently this was not a useful example.
    But to use them again as an example, if there is any conversion in the
    constructor as you stated, it would be in those deprecated ones.

    [ ... Date stores GMT millisecond value ... ]
    > Yeah, so? When did I say otherwise? I said that the value *RETURNED* by Date
    > was the local time.


    This is an imprecise statement. There are two methods that
    are not deprecated which return values and are not for comparison: getTime() and
    toString(). Do a myDate.getTime() and you get GMT milliseconds.
    Do a toString() and you get a string that is converted to the default
    TZ (not necessarily the local timezone), so 50% of the time you
    get a local time and 50% of the time you get GMT.

    > I never said it didn't hold the date internally as the
    > local date/time.


    Which I guess means you would say it does hold it in local time.
    If you did state that internally it is local time
    you'd be making an incorrect statement. It is better to speak
    about what the class does internally, instead of talking about
    what the constructor does or what a particular method does.
    Internally the value in a Date object is GMT. Which is what
    I was trying to say.

    > I never said it didn't use the value, and *did* say explicitly that Date
    > *does* get its value from System.currentTimeMillis(). What's your point in
    > arguing with me?


    To point out a few mis-statements. I hope I have succeeded.

    > You clarify something that wasn't in question. Nobody said that Date held
    > the local date/time...


    You just did above and in previous messages when you refered to constructors
    converting and I believe in your megation of what you claim you
    did say a few paragraphs above.

    Just to summarize, I'll contain to try to point out that:

    1. System.currentTimeMillis() always (to the abliity of the OS and hardware)
    returns a millisecond value since 1/1/1970 0:0:0 GMT.
    2. java.util.Date internally always uses GMT.
    3. java.util.Date.toString() uses the default TZ to create a localized string.
    4. java.util.Date.getTime() returns a GMT value as stated in the documentation.

    I hope everyone is on the same page now.

    But what of the original OP. Did he figure out his TZ problem? See other
    post in this thread.

    -Paul
     
    P.Hill, May 18, 2004
    #13
  14. Nelson

    P.Hill Guest

    Chris Smith wrote:

    > Sounds like the device thinks it's in GMT. Since the device doesn't
    > know its time zone, it would then be absolutely impossible to get that
    > information from anywhere else, unless you're connected to some remote
    > device that might know.
    >


    To get back to the problem of local time, apparently there is
    NO locale by default in a J2ME.
    http://java.sun.com/j2me/docs/wtk2.1/user_html/Ap_LanguageSupport.html#wp22327

    Unlike in the SE, Date.toString() in CLDC goes off to call special classes.

    public String toString() {
    return com.sun.cldc.util.j2me.CalendarImpl.toString(calendar);
    }

    which ends up using
    com.sun.cldc.util.j2me.TimeZone
    which says:
    "By default, the only supported
    time zone is UTC/GMT. Vendor-specific implementations
    may provide additional time zones."

    Of course, if the device's TZ is not set correctly then you can get confusing
    things where a machines apparent local time is attempted to be converted
    to GMT, but other problems are possible.

    -Paul

    -Paul
     
    P.Hill, May 18, 2004
    #14
  15. P.Hill wrote:

    > To get back to the problem of local time, apparently there is
    > NO locale by default in a J2ME.
    >

    http://java.sun.com/j2me/docs/wtk2.1/user_html/Ap_LanguageSupport.html#wp22327
    >
    > Unlike in the SE, Date.toString() in CLDC goes off to call special
    > classes.
    >
    > public String toString() {
    > return com.sun.cldc.util.j2me.CalendarImpl.toString(calendar);
    > }


    Careful. That's one implementation's way of returning the date as a String.
    Each handset may (and probably will) be getting that value differently.
    From where is the above code snippet taken?

    --
    /**
    * @author Darryl L. Pierce <>
    * @see The J2ME FAQ <http://mypage.org/mcpierce/j2mefaq.html>
    * @quote "What do you care what others think, Mr. Feynman?"
    * @geek echo '$_ = "Jvtu bopuifs Pfsm ibdlfs."; y/a-z/za-y/; print' |
    perl
    */
     
    Darryl L. Pierce, May 19, 2004
    #15
  16. P.Hill wrote:

    >> I said that System.currentTimeMillis() is *not* returning *local* time,
    >> and you can only say it *does* if your current locale is *GMT*.

    >
    > Sorry, we are in agreement here. currentTimeMillis() returns GMT.
    > I was not in any way trying to suggest, and don't see where I suggested,
    > that currentTimeMillis() is possibly a local time at any place in this
    > thread. If I did claim the currentTimeMillis() *might* return a local
    > time then I'd have to make a statement about conversion to the
    > internal format or claim that internally the value could be either
    > local or GMT. Reading my post I think you'll agree I was assuming
    > Date kept one consistent representation -- "GMT".


    You said earlier "The value of [Date and currentTimeMillis()] are exactly
    the same on a full size JDK.  The Date constructor gets its time from
    currentTimeMillis." This lead me to believe you were saying that both
    currentTimeMillis() and the date representation were the same. If you were
    talking about the internal representation of the date within the Date class
    then your statement is either vague or misleading.

    >> I also said
    >> that the Date constructor takes the value returned by
    >> System.currentTimeMillis() but does not return *that* as the local date
    >> either, but instead uses other information to convert that value into the
    >> local time when the local time is requested.

    >
    > But this is where the confusion starts. Constructors don't return
    > anything.


    And the confusion then is that I never said nor implied that they did.

    > And in the case of java.util.Date() the constructor doesn't do
    > any conversion. The result of a constructor is an object which interally
    > has a GMT value. When the time is requested, there IS NO CONVERSION unless
    > a readable string representation is requested then, and only then, is
    > there a conversion.


    That's what I was talking about. You put in one thing (a long value
    representing the date in a singular way) and you get out of the black box
    called Date a String that is your local date/time.

    >> So they do the conversion internally. Where did I say otherwise?

    >
    > With your use of the word constructor in both your last message and
    > in your penultimate message you suggest that on its way IN the value
    > might be converted in some way.


    The value is converted. But, the problem here is that you seem to think that
    "conversion" means "changed". Perhaps a better term would be "translated"?

    >> I said
    >> before that Date "uses your timezone to convert [the value from
    >> System.currentTimeMillis()] to the local time".

    >
    > Only the toString() method through the use of a SimpleDateFormat
    > does any TZ aware conversion. Now in the ME edition it uses a slight
    > different approach, but it still converts in the toString() method.


    Translates. It seems we're in violent agreement on this topic. ;)

    >> Why are you on about the
    >> deprecated constructors?

    >
    > I thought it would help to illustrate that Date does NOT store
    > a timezone aware value. Apparently this was not a useful example.
    > But to use them again as an example, if there is any conversion in the
    > constructor as you stated,


    I never stated that. The conversion/translation is in the *class*, with the
    constructor collecting the value in this case.

    > it would be in those deprecated ones.


    That constructor is not deprecated in the MIDP.

    > [ ... Date stores GMT millisecond value ... ]
    >> Yeah, so? When did I say otherwise? I said that the value *RETURNED* by
    >> Date was the local time.

    >
    > This is an imprecise statement.


    It seems there's quite a bit of imprecision here. I was talking about the
    toString() method. Yes, there are methods that will return the internal
    representation of the date as you pointed out, but they're not the one
    being discussed here.

    > There are two methods that
    > are not deprecated which return values and are not for comparison:
    > getTime() and toString(). Do a myDate.getTime() and you get GMT
    > milliseconds. Do a toString() and you get a string that is converted to
    > the default TZ (not necessarily the local timezone), so 50% of the time
    > you get a local time and 50% of the time you get GMT.
    >
    >> I never said it didn't hold the date internally as the
    >> local date/time.

    >
    > Which I guess means you would say it does hold it in local time.


    No. I'm saying that I *didn't* say anything about how the date is stored
    internally. Try not to put words into my mouth.

    > If you did state that internally it is local time
    > you'd be making an incorrect statement. It is better to speak
    > about what the class does internally, instead of talking about
    > what the constructor does or what a particular method does.
    > Internally the value in a Date object is GMT. Which is what
    > I was trying to say.


    I would say it's better to talk about what the public contract of the class
    does and not about what happens internally, since such is subject to
    potentially change.

    >> I never said it didn't use the value, and *did* say explicitly that Date
    >> *does* get its value from System.currentTimeMillis(). What's your point
    >> in arguing with me?

    >
    > To point out a few mis-statements. I hope I have succeeded.


    I think you've succeeded in pointing out some miscommunciations. You've
    assumed more than I've stated.

    >> You clarify something that wasn't in question. Nobody said that Date held
    >> the local date/time...

    >
    > You just did above and in previous messages when you refered to
    > constructors converting and I believe in your megation of what you claim
    > you did say a few paragraphs above.


    I said *nothing* about *what* is stored within the class. I said that it
    (the default constructor for Date) *gets* the current timestamp *from*
    System.currentTimeMillis() and also that the class *returns* a value that
    is the local version of that value. I said nothing about what is stored
    internally to the class; you're assuming that part.

    > Just to summarize, I'll contain to try to point out that:
    >
    > 1. System.currentTimeMillis() always (to the abliity of the OS and
    > hardware) returns a millisecond value since 1/1/1970 0:0:0 GMT.


    I said this.

    > 2. java.util.Date internally always uses GMT.


    I said nothing about how Date stores the value, though it's safe to assume
    this is probably the best practice.

    > 3. java.util.Date.toString() uses the default TZ to create a localized
    > string.


    No problem here.

    > 4. java.util.Date.getTime() returns a GMT value as stated in the
    > documentation.


    This only came up in this message from you.

    > I hope everyone is on the same page now.


    Yeah, but we've forgotten the point. :)

    > But what of the original OP. Did he figure out his TZ problem?


    That's been lost to antiquity...

    --
    /**
    * @author Darryl L. Pierce <>
    * @see The J2ME FAQ <http://mypage.org/mcpierce/j2mefaq.html>
    * @quote "What do you care what others think, Mr. Feynman?"
    * @geek echo '$_ = "Jvtu bopuifs Pfsm ibdlfs."; y/a-z/za-y/; print' |
    perl
    */
     
    Darryl L. Pierce, May 19, 2004
    #16
  17. Nelson

    P.Hill Guest

    Darryl L. Pierce wrote:
    > I said *nothing* about *what* is stored within the class. I said that it
    > (the default constructor for Date) *gets* the current timestamp *from*
    > System.currentTimeMillis() and also that the class *returns* a value that
    > is the local version of that value. I said nothing about what is stored
    > internally to the class; you're assuming that part.


    You said the "constructor returns", twice, I'm sorry, I had assumed that meant
    you were talking about what the Date object claims to be or is internally.
    The class does not "return a value when asked" it returns one of two values when
    asked. It seems you are now worried about the internal representation.

    By the way I am not sneaking into the implementation to claim what it does
    represent, I am stating what it public contract is:
    "the Date class is intended to reflect coordinated universal time" that is from
    the JavaDocs, that is not an implemenation detail. Date
    is a token that carries such things around. To think otherwise is
    to not understand a Date object.

    > This lead me to believe you were saying that both
    > currentTimeMillis() and the date representation were the same. If you were
    > talking about the internal representation of the date within the Date class
    > then your statement is either vague or misleading.


    Yup, that is what I was saying and it is the truth of all implementations
    currently in use, but you think otherwise for you want to make
    claims of conversion. For example, you said in your latest message:

    >That's what I was talking about. You put in one thing (a long value
    >representing the date in a singular way) and you get out of the black box
    >called Date a String that is your local date/time.


    Date.toString() may return a local String or it may not, in fact it
    is the ME editions where it is free to take the OR path and return GMT.
    But Date() is not some conversion object for making strings, you'd
    be wasting your time to use it as such. It is flyweight object, or
    token object which represents in a very small space a date/time combination
    like all objects it happens to have a toString() method. Like all
    toString() methods there is not guarentee what this might be as long
    as it consistent. There is no guarentee that it will come up with the TZ
    and produce local time in a Unix-like style.

    This is also a change in what you were stating, I quote you quoting
    yourself.

    >I said before that Date "uses your timezone to convert [the value from
    >System.currentTimeMillis()] to the local time".


    The only time a timezone comes into play is possibly in the toString()
    method and it converts the value currently in the Date() object which
    may not have anything to do with any System.currentTimeMillis().
    The above quote without even containing the word constructor again
    hints at timezones and currentTimeMillis coming together in the class
    somewhere. Since the only place the current time is mentioned in
    the API (we're sticking to the external contract right?) is in
    Date constructor then again you suggest TZ has something to do
    with constructing a Date object.

    >The value is converted. But, the problem here is that you seem to think that
    >"conversion" means "changed". Perhaps a better term would be "translated"?


    Recall I was quoting your sentences where you stated WHERE the conversion
    took place, in the constructor. I'm glad you are now stating explicitly
    that toString() MAY be the one which may doing such things.

    A good mental model, the stated contract, and all known implementations
    of Date() are a binary value since 1/1/1970. any other comments implying
    otherwise including statement about conversion in the constructor or use of
    terms like "conversion", "changed" or "translated" (from
    System.currentTimeMillis(), see your quote above) seems to me to obscure the
    picture unless you want to talk about toString() explicitly which until your
    very last post you did not state explicitly.

    >The conversion/translation is in the *class*,


    Too bad you stated it was in the constructor on two different occasions
    and claimed currentTimeMillis is translated using a TZ, thus starting down
    the path about internal represenation.

    >That constructor is not deprecated in the MIDP.


    Which one would that be? I was speaking of the one that take
    a String and variations that take seperate month, day, year values.
    Such don't exist in the MIDP edition. My god, what an
    imprecise statement! "not deprecated" might suggest to some
    that those old methods exist in MIDP. If any one is reading
    along, I'll point out to them that the only way
    the statement "That constructor is not deprecated in the MIDP"
    is true for the constructors in question which exist in the SE, but are
    deprecated, is that they don't exist at all in the MIDP, so they can't be
    deprecated. The old constructors where deprecated before MIDP or ME were
    defined, so they were just dropped in the ME and all variations of it.

    There are 4 deprecated ones in the JDK SE, all
    deprecated of for the same reason -- they would have to assume a TZ in order to
    do the right thing. Note that toString() has no such requirement to work with a
    TZ. The toString() doesn't have to return a local string tomorrow if SUN decides
    it doesn't want to. The programmers are only being polite to give you
    something that is recognizable. Notice that is typically formatted in a UNIX
    like manner. They chose an old defacto standard, aka prior art, but that is not
    part of the contract for Date.toString(). If you are using java.util.Date()
    to create a local time string, you are not working with just the defined
    interface, you are making an assumption about toString() which is not
    stated anywhere. I would not recommend that to anyone.

    You speak of not assuming implementations, I suggest you follow your own advice
    and not talk about local time and Date() objects, particular not in conjunction
    with currentTimeMillis().

    cheers,
    -Paul
     
    P.Hill, May 19, 2004
    #17
  18. P.Hill wrote:

    >> I said *nothing* about *what* is stored within the class. I said that it
    >> (the default constructor for Date) *gets* the current timestamp *from*
    >> System.currentTimeMillis() and also that the class *returns* a value that
    >> is the local version of that value. I said nothing about what is stored
    >> internally to the class; you're assuming that part.

    >
    > You said the "constructor returns", twice,


    I said no such thing. Please quote where I said the constructor returns
    anything.

    > I'm sorry, I had assumed that
    > meant you were talking about what the Date object claims to be or is
    > internally. The class does not "return a value when asked" it returns one
    > of two values when
    > asked.


    Sorry, what's the difference between those two statements?

    > It seems you are now worried about the internal representation.


    What *is* your problem? I said specific *not* to worry about internal
    representations and only to focus on the public contracts in the message to
    which you're replying. You're now trying to claim I've said the exact
    opposite. Why?

    > By the way I am not sneaking into the implementation to claim what it does
    > represent, I am stating what it public contract is:
    > "the Date class is intended to reflect coordinated universal time" that is
    > from
    > the JavaDocs, that is not an implemenation detail. Date
    > is a token that carries such things around. To think otherwise is
    > to not understand a Date object.


    I never claimed otherwise. I said that the Date object takes the value from
    currentTimeMillis() in the default constructor and will return to you a
    representation of that date in the local format in the MIDP.

    > > This lead me to believe you were saying that both
    > > currentTimeMillis() and the date representation were the same. If you
    > > were talking about the internal representation of the date within the
    > > Date class then your statement is either vague or misleading.

    >
    > Yup, that is what I was saying and it is the truth of all implementations
    > currently in use,


    Not in the MIDP. The MIDP returns the local date.

    > but you think otherwise for you want to make
    > claims of conversion. For example, you said in your latest message:
    >
    > >That's what I was talking about. You put in one thing (a long value
    > >representing the date in a singular way) and you get out of the black
    > >box called Date a String that is your local date/time.


    In the MIDP it does, which is what the OP was asking for.

    > Date.toString() may return a local String or it may not, in fact it
    > is the ME editions where it is free to take the OR path and return GMT.


    That's what the OP asked for, and that's the answer to his question.

    > But Date() is not some conversion object for making strings, you'd
    > be wasting your time to use it as such. It is flyweight object, or
    > token object which represents in a very small space a date/time
    > combination like all objects it happens to have a toString() method. Like
    > all toString() methods there is not guarentee what this might be as long
    > as it consistent. There is no guarentee that it will come up with the TZ
    > and produce local time in a Unix-like style.
    >
    > This is also a change in what you were stating, I quote you quoting
    > yourself.
    >
    > >I said before that Date "uses your timezone to convert [the value from
    > >System.currentTimeMillis()] to the local time".

    >
    > The only time a timezone comes into play is possibly in the toString()
    > method and it converts the value currently in the Date() object which
    > may not have anything to do with any System.currentTimeMillis().


    Mate, that's what the OP asked for, and that's the answer to his question.

    <snip>

    --
    /**
    * @author Darryl L. Pierce <>
    * @see The J2ME FAQ <http://mypage.org/mcpierce/j2mefaq.html>
    * @quote "What do you care what others think, Mr. Feynman?"
    * @geek echo '$_ = "Jvtu bopuifs Pfsm ibdlfs."; y/a-z/za-y/; print' |
    perl
    */
     
    Darryl L. Pierce, May 20, 2004
    #18
    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. Michael Pfeifer
    Replies:
    4
    Views:
    421
    red floyd
    Dec 17, 2003
  2. Michael Pfeifer
    Replies:
    4
    Views:
    658
    red floyd
    Dec 17, 2003
  3. john

    GMT/UTC help

    john, Sep 8, 2003, in forum: Javascript
    Replies:
    1
    Views:
    104
    Dr John Stockton
    Sep 8, 2003
  4. Skip Montanaro

    pytz question: GMT vs. UTC

    Skip Montanaro, Jan 29, 2014, in forum: Python
    Replies:
    25
    Views:
    196
    Grant Edwards
    Feb 2, 2014
  5. Chris Angelico

    Re: pytz question: GMT vs. UTC

    Chris Angelico, Jan 29, 2014, in forum: Python
    Replies:
    0
    Views:
    75
    Chris Angelico
    Jan 29, 2014
Loading...

Share This Page