«

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

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...t.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(calen dar);
}

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 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...t.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(calen dar);
> }

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
*/

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 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 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
*/