Darryl said:
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
