What a mess: Date, milliseconds, GregorianCalendar

[Paul Lutus]

Erwin Moller wrote:

/ ...

I have 1 question left:
Why didn't Sun just release a better version of Date?

Most likely they hired the least expensive programmers they could find, with
the predictable result that the code reflects the qualifications of those
individuals. Remember, Sun is a corporation, not a monastery.

(the GoodDate class
or something)
Or should I consider GregorianCalendar as the improved version?

One could make the argument that GregorianCalendar is 80% of what Date
should have been originally -- all that is needed is to add what remains of
Date to it.

I ask this because I find myself doing basic stuff like getting intervals
(or elapsed time) based on 2 dates.

And as you have seen, that is trivial. Just get the difference between two
dates in milliseconds, then divide by an appropriate constant depending on
the desired result.

(A bit like public int daysBetween (Day day) in
http://geosoft.no/software/day/Day.java.html (posted by Jacob) )

What I miss in GregorianCalendar is things like:
(phantasy-code)
GregorianCalendar Cal1 = new GregorianCalendar(2004,7,2);
GregorianCalendar Cal2 = new GregorianCalendar(2005,8,28);
// express the difference in seconds.
double dDiffInSecs = GregorianCalendar.getDiff(Cal1,Cal2,CALENDAR_SEC);
// express the difference in days.
double dDiffInDays = GregorianCalendar.getDiff(Cal1,Cal2,CALENDAR_DAY);

But these are all trivially acquired by dividing the original millisecond
result by an appropriate constant. It won't work for months or years, for
obvious reasons.

Also, in Java, you could extend GregorianCalendar to provide these extra
methods in a matter of minutes (no pun intended).

Ideally the getDiff method would correct for any leapseconds,
timesettings, etc.

Calendar difference results don't need to make those kinds of adjustments
(assuming both values are from the same source).

Maybe similar are classes around somewhere and I just missed them
completely.

Yep. "They" are called GregorianCalendar, plus a small bit of effort on your
part.

It has been many years now since I coded VBscript, but if memory serves me
well those VB guys had functions that did this.

But not correctly. They had the same problems that plagued Java. And now VB
has been scheduled for abandonment by Microsoft, a lame effort to get
people to switch all their code to C# or something else.

 

[Paul Lutus]

And what of those places that don't use the Gregorian calendar?

Maybe we should stick to one topic per thread. Your point is correct, but it
is orthogonal to the original topic.

I think
the separation between Date and Calendar is correct.

If true, then the fact that GregorianCalendar tries to do what Date did/does
is already an error. I think they created GregorianCalendar to avoid
confusion and make a clean break with the compromised past.

 

[P.Hill]

// express the difference in seconds.
double dDiffInSecs = GregorianCalendar.getDiff(Cal1,Cal2,CALENDAR_SEC);
// express the difference in days.
double dDiffInDays = GregorianCalendar.getDiff(Cal1,Cal2,CALENDAR_DAY);

I certainly have such classes and they are tested, so drop me a line
and I can send you some code.

My Code would be much more OO and something like:

double dDays = cal1.getDiff( Calendar.DAY, cal2 );

I hope you corrected both the daylight savings and the difference in days
between two arbitrary times bug in your code.

-Paul

 

[Paul Lutus]

I think you didn't quite catch Paul Hill's point. What he was stressing
was the fact that the Date and the Calendar classes are two different
things altogether.

Yes, but the class being discussed is GregorianCalendar, a class with some
significant overlap with Date. With respect to this issue, Calendar is
cleaner, less compromised if you will.

java.util.Date (once you delete the deprecated methods
from it) is a lightweight class which is an abstraction for an instance in
time - (which is an essential component in any computation involving
time).

All true, and GregorianCalendar has a default constructor that serves the
purpose of doing without Date. All I am saying is there is a gray area that
both Date and GregorianCalendar seem to try to fill simultaneously (not
counting the deprecated methods of Date).

Trying to use a Calendar object which is much more complex beast
for this is certainly overkill.

The fact that a class has a lot of unused members doesn't make the compiled
result any larger if a single class method is invoked. So the complexity of
the class isn't really an issue, except perhaps in locating the desired
method in the documentation.

You know, this is really rather hypothetical. No one is going to actually do
any of these things, which gives us a certain license to imagine things we
might not even articulate if a tangible outcome were possible.

 

[P.Hill]

Two classes, one nearly deprecated out of existence, have identical
constructors weith identical outcomes. Please remember this is a
hypothetical discussion -- IF we could start over, etc., etc..

As Babu stressed, one is lightweight the other is huge (and and kludgy, yet
functional). GregorianCalendar is several tens of times larger than a Date.

GregorianCalendar is the topic. They both have constructors that serve the
same purpose and produce the same outcome. It suggests that the designers
of GregorianCalendar wanted to save a few steps for people constructing an
object set to the current time.

Nothing wrong with an existing or a hypothetical design which saves users a few
steps.

Yes, and you are making my point. GregorianCalendar uses Date to accomplish
some things that *might* be better handled within GregorianCalendar, now
that Date is nearly deprecated to death,

No, let's start again. It is reduced in its role. It HOLDs a timestamp. You use
it to pass around a Timestamp. It is not near death, it just has a VERY humble
role. In a future implementation we'd call it DateTime or Timestamp.

and granted the very hypothetical
nature of this entire discussion. As I pointed out, thay already share a
constructor, for all practical purposes.

Sharing a constructor is just the 1st step, but you seem to think it
practically makes them the same.

But I see the difference here; you are suggesting that if the bigger brother
class can do all the little one can why not get rid of the little one?
Well the answer is that the fancier one is just too big for passing around
and contains literally 10s of things many uses of a timestamp don't need.

Let's say I need to send your application the time of an appointment, either of
a human or machine rendevous. I don't send you "October 29th 2:30 PM Nepalese
Daylight Time" or "1:00 AM Indiana Standard Time" I send a GMT timestamp, but
not as a string which I could, but as a nice compact binary value. Then all
machines need not know either what Nepalese Daylight time nor what Indiana
Standard Time is, nor what either's offset from GMT is. This is the use for a
java.util.Date (or some better future replacement).

I certainly don't need to send any other bit of software a binary time plus that
binary time separated out into year, month, day, hour, minute, second,
millisecond, day of week, day of year, ... , which timezone we are in, which
locale we are working from or anything else.

Okay then what is (Gregoirian)Calendar for? It is to do the conversion from the
token of a binary time to WHATEVER calendar. In our case Gregorian, in someone
elses case it could be any other calendar. A human might want to check that a
reqested datetime is not a poor date to schedule. For example, suggesting an
afternoon reception in the month of Ramadan in Saudi Arabia might be a bad idea,
but a late dinner would be just the thing.

So maybe you can suggest how you'd make a future GregorianCalendar object
which can be sent around that contains an efficient representation, but can do
all that is needed of a calculating, converting, timezone and locale, DLS aware
Calendar object like (Gregorian)Calendar.

I hope you're beginning to understand the separate, yet coupled role of both
something like a Date object and something like a GregorianCalendar object.

-Paul

 

[Erwin Moller]

Erwin Moller wrote:

/ ...


Most likely they hired the least expensive programmers they could find,
with the predictable result that the code reflects the qualifications of
those individuals. Remember, Sun is a corporation, not a monastery.


One could make the argument that GregorianCalendar is 80% of what Date
should have been originally -- all that is needed is to add what remains
of Date to it.


And as you have seen, that is trivial. Just get the difference between two
dates in milliseconds, then divide by an appropriate constant depending on
the desired result.


But these are all trivially acquired by dividing the original millisecond
result by an appropriate constant. It won't work for months or years, for
obvious reasons.

Also, in Java, you could extend GregorianCalendar to provide these extra
methods in a matter of minutes (no pun intended).

Hi Paul,

Thanks for your respons.

Forgive me for being slow on this, but I am still confused.
:-/ <-- me

I understand the milliseconds (Epoch Unixtime).
I also understand that the number of milliseconds since 1970 are a clean
messure of the passing of time.
But for me it is far from trivial to express things as elapsed months or
days using millis only.

Yes I know how many millis we have in a day.
I could use 1000*60*60*24
(even that needs to be corrected sometimes I understand)

But how many days do I have in a month?
And how many days in a year? (leapyears)

Is that trivial?

Regards,
Erwin Moller

 

[Paul Lutus]

Erwin Moller wrote:

/ ...

Forgive me for being slow on this, but I am still confused.
:-/ <-- me

I understand the milliseconds (Epoch Unixtime).
I also understand that the number of milliseconds since 1970 are a clean
messure of the passing of time.
But for me it is far from trivial to express things as elapsed months or
days using millis only.

I already explained these are not trivially calculable.

Yes I know how many millis we have in a day.
I could use 1000*60*60*24
(even that needs to be corrected sometimes I understand)

But how many days do I have in a month?

Approximately 365.25 / 12

And how many days in a year? (leapyears)

Approximately 365.25.

Both approximations.

I already explained these cases do not apply, because neither of them is
logical in a mathematical sense. But GregorianCalendar has ways to try to
come up with these values (better methods than the above approximations).

 

[P.Hill]

I think they created GregorianCalendar to avoid
confusion and make a clean break with the compromised past.

You think wrong. There was no intention to replace Date, only to separate
out some of it functionality leaving Date to serve as a simple holder and
putting all the locale and calendar algorithm knowledge in a separate class,
not withstanding that both the holder and the algoirthm can start with a binary
number.

Are you following this idea yet? Do you understand the difference between
a simple class with one member used as a mini representation of something
and a large class with an array of separate numeric fields plus timezone, locale
etc.?

Yes, the compiled code is the same, but the amount of memory on the heap is
significantly different. Imagine a list of Dates verses a list of
GregorianCalendars (or any Calendar for that matter). Imagine sending a set of
serialized dates somwhere vs. sending a set of Calendars (Gregorian or otherwise).

-Paul

 

[P.Hill]

And as you have seen, that is trivial. Just get the difference between two
dates in milliseconds, then divide by an appropriate constant depending on
the desired result.

Bzzt, wrong; thank you for playing.

But these are all trivially acquired by dividing the original millisecond
result by an appropriate constant.

Bzzt, wrong, thank you for playing.

Calendar difference results don't need to make those kinds of adjustments
(assuming both values are from the same source).

If you calculate them using milliseconds, which you said was trivial,
you will need to take these into consideration.

Bzzt, three strikes you are out. Please stop giving incorrect advice.
I certainly wouldn't put down the coder at IBM (which is where the class
was implemented not SUN) who implemented a dozen calculations if you
can't do just one yourself.

And what kind of assumption is 'from the same source'? Calendars have locale
and timezone, so they can do the conversion from a binary (Unix-style) time
to locale sensetive fields. That is what they are for, we both agree on that!

Yep. "They" are called GregorianCalendar, plus a small bit of effort on your
part.

But apparently more effort than your willing to put in to realize that your
advise is still wrong. subtract and divide by milliseconds won't get you the
answer in many cases, and using a Calendar in all places that you use a Date now
is just an idea from someone who doesn't seem to accept the idea of a token class.

-Paul

 

[P.Hill]

Hi Paul,

Hi Paul Lutus,

I think he is asking me -- Paul *Hill* -- this since I posted code that actually
worked and spoke of the Unix epoch etc.

-Paul

 

[Babu Kalakrishnan]

Yes, but the class being discussed is GregorianCalendar, a class with some
significant overlap with Date. With respect to this issue, Calendar is
cleaner, less compromised if you will.

Uh ???

Calendar is just an abstract superclass - with GregorianCalendar just being
an implemeentation provided by Sun to represent (surprise - surprise) a
Gregorian Calendar. So whatever I said applies to the latter as well. Also
what is the overlap that you're talking about ?

All true, and GregorianCalendar has a default constructor that serves the
purpose of doing without Date. All I am saying is there is a gray area that
both Date and GregorianCalendar seem to try to fill simultaneously (not
counting the deprecated methods of Date).

Can you elaborate on what that gray area is ? I don't really see any if you
don't count the deprecated methods.

The fact that a class has a lot of unused members doesn't make the compiled
result any larger if a single class method is invoked. So the complexity of
the class isn't really an issue, except perhaps in locating the desired
method in the documentation.

Would you advice anyone to use a JTextArea with number of rows set to 1 and
wrapping off to simulate a JTextField ? It would look the same and probably
function more or less similarly..

The basic point I'm trying to make is that a blanket advice like "Do not use
Date - use Calendar instead" is *wrong*. Each class has its own place and
value, and one should use the appropriate one depending on the application.

BK

 

[Paul Lutus]

Bzzt, wrong; thank you for playing.

You are entirely mistaken. Two millisecond values acquired from the
GregorianCalendar class can always be relied on to produce a correct
differential of any time units up to months (not including months) by
application of a constant divisor.

IOW:

IF the millisecond differential is correct for the time interval,

THEN so are the seconds, minutes, hours and days. That was my limited claim
in the post you objected to.

Perhaps you shoud think and read before posting.

Bzzt, wrong, thank you for playing.

FALSE. Post your evidence, or your apology. You have two choices. There is
no third choice you will want to contemplate.

If you calculate them using milliseconds, which you said was trivial,
you will need to take these into consideration.

False. Either the class is broken, or any GregorianCalendar object contains
an accurate representation of the number of milliseconds from 1/1/1970. And
the class is not broken.

Bzzt, three strikes you are out. Please stop giving incorrect advice.

At this point, you have two choices. You can try to back up your position
with evidence (there is none) or you can apologize.

I certainly wouldn't put down the coder at IBM (which is where the class
was implemented not SUN) who implemented a dozen calculations if you
can't do just one yourself.

Prove it. Post your evidence that two millisecond values from two
GregorianCalendar objects cannot produce an accurate delta-t useful for
milliseconds, seconds, minutes or hours.

And what kind of assumption is 'from the same source'?

It is a necessary condition for the claim I am making, the one you
brainlessly objected to.

Calendars have
locale and timezone, so they can do the conversion from a binary
(Unix-style) time
to locale sensetive fields. That is what they are for, we both agree on
that!

If that is true, then your objection has no basis. If GregorianCalendar
consistently uses timezone and other information to acquire a consistent
millisecond representation as set out above, then your entire objection is
false. It does, and it is.

But apparently more effort than your willing to put in to realize that
your
advise is still wrong.

Post your evidence or your apology. If you do neither, you are marked as a
hypocrite and a troll.

subtract and divide by milliseconds won't get you
the answer in many cases,

FALSE. In each of the cases I clearly stated in the original post,
GregorianCalendar can be relied on to produce a correct differential of:

1. Millisconds.
2. Seconds.
3. Minutes.
4. Hours.

through the trivial applicaiton of a constant. And only if the
GregorianCalendar objects arise from the same source.

and using a Calendar in all places that you use
a Date now is just an idea from someone

Which someone was that? I never suggested any such thing.

Read the post before trying to reply to it.

who doesn't seem to accept the
idea of a token class.

Who was that again? I have never made any claims about the Calendar class.

 

[Paul Lutus]

Hi Paul Lutus,

I think he is asking me -- Paul *Hill* -- this since I posted code that
actually worked and spoke of the Unix epoch etc.

Be that as it may, GregorianCalendar can and does produce accurate results
for the simpler time units for any two dates in its domain of
applicability, as explained above.

 

[Paul Lutus]

You think wrong.

Stop arguing with someone who prefaces his remarks with a hypothetical
qualifier. You have no idea whether this was the actual intention, and
neither do I.

There was no intention to replace Date,

NO ONE made this claim. Do you always argue with straw men of your own
construction, when things get too boring for your tastes?

only to separate
out some of it functionality leaving Date to serve as a simple holder and
putting all the locale and calendar algorithm knowledge in a separate
class, not withstanding that both the holder and the algoirthm can start
with a binary number.

Are you following this idea yet?

Are you aware that if the entire edifice were to be recreated today, or
refactored without attention to the legacy issue, the result would
certainly not be a Date class with six surviving methods out of an original
29, and a GregorianCalendar class with no way to acquire a present time
(which is why GregorianCalendar knows how to do this).

Most likely there would be a time class and a date class. Logically, the
latter would extend the former, which is what has happened to
GregorianCalendar in a roundabout way.

Do you understand the difference between
a simple class with one member used as a mini representation of something
and a large class with an array of separate numeric fields plus timezone,
locale etc.?

Do you understand inheritance? IMHO it would have made more sense for
GregorianCalendar to extend Date(*). This would produce the outcome I have
been going on about, and that is provided in the default GregorianCalendar
constructor, which you may notice behaves exactly as the default Date
constructor does.

* This wasn't practical because of all those deprecated methods in Date,
whose names were needed in its replacement. It would have created a lot of
confusion.

Imagine sending a
set of serialized dates somwhere vs. sending a set of Calendars (Gregorian
or otherwise).

Imagine someone who builds strawman arguments when real arguments become
boring.

 

[Paul Lutus]

Uh ???

Calendar is just an abstract superclass - with GregorianCalendar just
being an implemeentation provided by Sun to represent (surprise -
surprise) a Gregorian Calendar. So whatever I said applies to the latter
as well. Also what is the overlap that you're talking about ?

The fact that the default comnstructors of both Date and GregorianCalendar
produce an object initialized with the present system time. This frees
GregorianCalendar from a reliance on Date in many (perhaps most) typical
cases.

Can you elaborate on what that gray area is ? I don't really see any if
you don't count the deprecated methods.

See above.

Would you advice anyone to use a JTextArea with number of rows set to 1
and wrapping off to simulate a JTextField ? It would look the same and
probably function more or less similarly..

True, but it addresses a different issue. My point is the use of large,
complex classes don't necessarily result in large, complex programs. It has
to do with the number of fields in each class and whether static methods
can or cannot be used to achieve the desired results.

The basic point I'm trying to make is that a blanket advice like "Do not
use Date - use Calendar instead" is *wrong*.

And? No one offered this advice. I pointed out that GregorianCalendar's
default constructor obviates a role for Date in many programs.

Each class has its own place
and value, and one should use the appropriate one depending on the
application.

True, and somewhat orthogonal in a discussion with the hypothetical
conditions this one has.

 

[P.Hill]

Most likely there would be a time class and a date class.

Most likely there would be a Timestamp class which is the role
of Date and there would be a Calendar class for ripping out all
those fields from a Timestamp. There might also be a Date class for
just whole days, but that is another issue since neither Date nor Calendar
try to provide just the day part.

Do you understand inheritance? IMHO it would have made more sense for
GregorianCalendar to extend Date(*).
YMMV

Imagine someone who builds strawman arguments when real arguments become
boring.

I am not the only one who thought you were trying to suggest that
GregorianCalendar was a good replacement for Date. It isn't a good
replacement in MOST cases because it has lots of internal state unrelated
to a simple date-time stamp. I am glad you agree. Now back to algorithms which
actually work.

-Paul

 

[P.Hill]

Two millisecond values acquired from the
GregorianCalendar class can always be relied on to produce a correct
differential of any time units up to months (not including months) [...]

THEN so are the seconds, minutes, hours and days. [...]

Prove it. Post your evidence that two millisecond values from two
GregorianCalendar objects cannot produce an accurate delta-t useful for
milliseconds, seconds, minutes or hours.

[...]

If you actually state the problem accurately and tell me whether you
want days or not then I will show you examples of two arbitrary time values set
into a GregorianCalendar that using a ( moment2 - moment1 ) / millisecsPerUnit
(your algorithm) will NOT produce the same value for the same day (when
calculating days) for various trivial and various obscure values.

It is a necessary condition for the claim I am making, the one you
brainlessly objected to.

I do not need to invent dates in different TZs to show the problem, so
I won't bother pursuing the discussion of generalities or applicability
of an algorithm.

If that is true, then your objection has no basis. If GregorianCalendar
consistently uses timezone and other information to acquire a consistent
millisecond representation as set out above, then your entire objection is
false. It does, and it is.

But grabbing millisecond values and dividing is not leveraging much
information/algorithms of GregorianCalendar.

FALSE. In each of the cases I clearly stated in the original post,
GregorianCalendar can be relied on to produce a correct differential of:

1. Millisconds.
2. Seconds.
3. Minutes.
4. Hours.

No we started with a discussion of days, you even inconsistently stated above
that it would work up to but not including months. I'll ignore the question of
whether "any time units up to months (not including months)" also includes weeks.

Your suggesting of reading first is a good one, you might take your own advice.
I already showed Erwin where his code and yours derived from it was broken.
And he is pursuing improvements in his code. I think you need to try reading
that. My code even came with jUnit test cases.
It was posted last night at "5:46 PM". It is a reply to John B. and starts with
"It is many things:". What did I not show in those classes?

I'd also suggest testing the code you post more. Date-time calculation can be
tricky beasts despite looking deceptively trivial.

I'm not planning any apologies, but if I have time this evening or weekend I might
1. Take the code you posted
2. Change it to return just number of days
3. Change it to take any two Calendars loaded with any datetime value.
4. Show many groups of cases which don't work.

Note: the above seems to fit what you are saying even though the original
problem worked with a later time (ElectionStart or End) which was fixed at
midnight. Yet, even for this limiting criteria, I can show you where two
arbitrary times on the same calendar day will return different values when
compared to another datetime fixed at some arbitrary midnight. I think
we'd both agree that different delta days for the times on the same calendar
date would be a broken algorithm.

If you want to clarify the problem, please do, I'm game; but then the
question will be will you apologize?

-Paul H.

 

[Cid]

You know what? I advocate that it isn't the Date class that's broken.
It's the damnable world's assorted calendars and
written-on-my-underpants-tag daylight savings time schemes.

Let's undeprecate Date and have the UN sort out universal take it or
leave it time (UTIOLIT).

Tentatively, I suggest that UTIOLIT also does not recognize time
zones. Instead you just deal with the fact that daytime in China is
from 6pm to 8am or some noise like that.

Also:
- flat tax
- Subway will put veggies on top meat like a normal God-fearing
sandwhich
- car engines run on clean burning hydrogen, cold fusion, or good
intentions
- Israel becomes a world historic park and nobody from any country is
allowed to live there permanantly, but can visit (sans weapons)
- Schwarzeneger to be made president 2004 on condition that he wear
leather and sunglasses during all speeches.

*Fleeeeeeeeeeeeeeeeeeeeeeeee*

 

[Paul Lutus]

Two millisecond values acquired from the
GregorianCalendar class can always be relied on to produce a correct
differential of any time units up to months (not including months) [...]

THEN so are the seconds, minutes, hours and days. [...]

Prove it. Post your evidence that two millisecond values from two
GregorianCalendar objects cannot produce an accurate delta-t useful for
milliseconds, seconds, minutes or hours.

[...]

If you actually state the problem accurately and tell me whether you
want days or not then I will show you examples of two arbitrary time
values set into a GregorianCalendar that using a ( moment2 - moment1 ) /
millisecsPerUnit (your algorithm) will NOT produce the same value for the
same day (when calculating days) for various trivial and various obscure
values.

Post your evidence. This is not creative writing class. Any pair of values,
*if* they represent an accurate conversion to milliseconds from the
original date/time formats, will also create a correct differential of
INTEGER milliseconds, seconds, minutes, hours, and days.

That was my original claim. Prove it wrong.

I do not need to invent dates in different TZs to show the problem,

If you produced consistent dates in different time zones, dates for which
GregorianCalendar failed to produce the expected millisecond value, you
wouild have uncovered a failure in the class, not my claim.

OBVIOUSLY creating two calendar objects, one with 12:01, August 8th in PST,
another with 15:00 August 9th in EST, if the differential is NOT 23:59:00,
the class is broken, not my claim. Your argument is a red herring.

so
I won't bother pursuing the discussion of generalities or applicability
of an algorithm.

Translation: "I have no evidence, in any case, this is the post-modern
version of reality. You didn't seriously expect to defend my claim, did
you?"

As a matter of fact, no, I didn't. That is why I demanded that you do so.
You, by contrast, expected a post-modern end to a post-modern debate.
Surprise, surprise: there really are facts that are not a matter of
subjecive opinion.

But grabbing millisecond values and dividing is not leveraging much
information/algorithms of GregorianCalendar.

Red Herring. Where's your evidence to back up your claim that I was offering
false advice?

No we started with a discussion of days,

Sorry. Left out days.

5. Days.

you even inconsistently stated
above
that it would work up to but not including months.

How is that inconsistent? Months do not follow logical standards as the
smaller units do. I left them out for a reason. Post your evidence, not
your opinion.

I'll ignore the
question of whether "any time units up to months (not including months)"
also includes weeks.

Weeks, if one excludes assumptions and conventions about their starting
points, are trivial to accommodate. I left them out because you are so
clearly intent on arguing that I saw the problem (not with weeks, but with
you).

Your suggesting of reading first is a good one, you might take your own
advice.

Prove it. I offered correct advice, incluing example code. Post your
evidence to back up this remark:

"Please stop giving incorrect advice."

I already showed Erwin where his code and yours derived from it
was broken.

You have done no such thing. My claim is very simply (again) that:


IF GregorianCalendar produces correct millisecond differentials between two
such objects,

THEN the larger derived units, less than months, ARE ALSO CORRECT. That was
my claim, the one you falsely objected to.

And he is pursuing improvements in his code. I think you need
to try reading
that.

I read it. Apropos this discussion of converting milliseconds to days, it is
total bullshit. The suggested conversion to days (by integer division from
milliseconds) always correctly truncates to the nearest complete day
regardless of how one manipulates the constructor. One can choose to
include fractional days, but this is outside the original example.

Therefore you have not defended your claim that I offered bad advice.

My code even came with jUnit test cases.
It was posted last night at "5:46 PM". It is a reply to John B. and starts
with
"It is many things:". What did I not show in those classes?

Common sense? If it is 12:01 on August 8, that is less than a day away from
12:00 August 9th. Integer division of millisecond values correctly says
that there are zero days left. Floating division is always an option, but
the original request was for a counter of integer days.

I'd also suggest testing the code you post more.

Believe me, I have forgotten more about this kind of coding that you can
ever hope to know.

Date-time calculation
can be tricky beasts despite looking deceptively trivial.

And you can produce any number of red herrings, like claiming that 23 hours
and 59 minutes is neither one nor zero integer days. And as you have done.

I'm not planning any apologies,

Yes, as I expected. But you need to apologize, as already stated, and for
the reasons stated. You are wrong. Your objections don't hold water.

but if I have time this evening or weekend
I might 1. Take the code you posted
2. Change it to return just number of days
3. Change it to take any two Calendars loaded with any datetime value.
4. Show many groups of cases which don't work.

False. It always produces the expected result in integer days. If it were to
fail, this would indict GregorianCalendar, not my original claim.

Note: the above seems to fit what you are saying even though the original
problem worked with a later time (ElectionStart or End) which was fixed at
midnight.

Be that as it may, it always works for educated people. Any time less than
24 hours is zero integer days, the original criterion.

Yet, even for this limiting criteria, I can show you where two
arbitrary times on the same calendar day will return different values when
compared to another datetime fixed at some arbitrary midnight.

"Some arbitrary midnight"? I already limited you to outputs from the same
source, in a vain effort to keep you from putting up this kind of
irrelevant argument.

I think
we'd both agree that different delta days for the times on the same
calendar date would be a broken algorithm.

This doesn't even address the fact that you were wrong about the nature of
my advice.

If you want to clarify the problem,

What? IF two calendar objects produce correct millisecond values, THEN their
differential can be relied on to produce accurate integer values for the
larger units of time up to, but not including, months. No clarification is
needed.

please do, I'm game; but then the
question will be will you apologize?

Since you have already stated you will not apologize, you have lost the
right to ask this.

 

[Babu Kalakrishnan]

The fact that the default comnstructors of both Date and GregorianCalendar
produce an object initialized with the present system time. This frees
GregorianCalendar from a reliance on Date in many (perhaps most) typical
cases.

No further comments - it would be a waste of time.

And? No one offered this advice. I pointed out that GregorianCalendar's
default constructor obviates a role for Date in many programs.

It wasn't the "default constructor" statement I was referring to - but your
message very early in the thread (on 19th August 7:57 PM) in which you wrote :

<QUOTE>

That is not a problem, as most of Date has been deprecated, and it appears
people are being advised to avoid Date for now projects.

--
Paul Lutus
http://www.arachnoid.com
</QUOTE>

My (rather limited) understanding of the English language tells me that the
indirect sentence "people are being advised" implies that there is someone out
there (about whom you are aware of atleast through hearsay) who is handing out
such an advice. My reference was about that *someone*. Does that make your
statement "No one offered this advice" a possible lie ? (for which a hypothetial
person might demand: Apologize now - or be damned to be branded a liar all your
life - There is no third alternative, etc.. etc.. ? )

And for gods sake, please don't come up with arguments like "That statement
only said "avoid Date" - the term "use Calendar instead" wasn't present".
Noone would buy an argument that It actually meant : "Avoid Date - write
your own class instead" or "use a long instead".

BK