Hi group,

(Sorry for complaining)
Is it just me or do dates, milliseconds, GregorianCalendar completely 
confusing? 

I needed to build a simple JSP that displays a simple countdown for an 
election.
It should show how many days untill elections start.
During elections it should show how many days are left to vote, and when the 
election closingdate is over it should say: elections are passed.

This took me 4 hours and a lot of frustration. the API wasn't really a help 
either.
I came up with the following huge script. (at the end)
I code such things in PHP on 3 lines...

I was just wondering: Am I missing something completely or is working with 
dates really confusing?
(Like the double getTime().getTime() constructions.)

What is your experience?

Thanks for your time.
And again, sorry for the ranting. 
I love working with Java, but the Date-related logic just isn't compatible 
with my brains. :-(

Regards,
Erwin Moller


-------------------


<%@ page import="java.util.Date" %>
<%@ page import="java.util.Calendar" %>
<%@ page import="java.text.SimpleDateFormat" %>
<%@ page import="java.util.Date" %>
<%@ page import="java.util.Calendar" %>
<%@ page import="java.util.GregorianCalendar" %>
<%
    // this file represents a countdontcounter

    // We have 2 dates:
    // startElectionDate = startdate of elections
    // endElectionDate = enddate of elections
    
    // format them: (yyyy,mm,dd)
    // warning, month is 0 based! 0 = januari, 1 = februari
    GregorianCalendar startElectionGregorianCalendar = new 
GregorianCalendar(2004, 7 , 2);
    GregorianCalendar endElectionGregorianCalendar = new 
GregorianCalendar(2004, 8, 1);    
    
    GregorianCalendar nowGregorianCalendar = new GregorianCalendar();
    
    long mssecInADay = (1000*60*60*24);
    
    // if <0 already passed
    double dDaysToStartDate = (double) 
(startElectionGregorianCalendar.getTime().getTime() -  
nowGregorianCalendar.getTime().getTime()) / mssecInADay;

    // if <0 already passed
    double dDaysToEndDate = (double) 
(endElectionGregorianCalendar.getTime().getTime() -   
nowGregorianCalendar.getTime().getTime()) / mssecInADay;
    
    String strDisplay = "";
    if (dDaysToStartDate >0){
        strDisplay = ""+dDaysToStartDate+" days untill elections.";
    } else {
        if (dDaysToEndDate >0) {
          strDisplay = "Elections running. you have "+dDaysToEndDate+" days 
to vote left.";
        } else {
          strDisplay = "Voting is over.";
        }
    }
%>
<!-- Start countdown -->
      <%= strDisplay %>
<!-- End countdown -->

Erwin Moller wrote:

> (Sorry for complaining)
> Is it just me or do dates, milliseconds, GregorianCalendar completely 
> confusing? 

You're allowed to complain!

It's not a mess as it contains a lot of complex logic to handle
the complicated world of calendars, days and time, but the API
is not suitable for the many simple cases like yours.

The main problem (I think) is that dates and times are mixed into
the same class: java.util.Date. It is difficult to work with *dates*
without getting into all kind of time issues.

You can look at http://geosoft.no/software/day/Day.java.html
where only the *day* part of a calendar is exposed, and a set of
simple date arithmetic methods like you requests has been included.

Erwin Moller wrote:

> Hi group,
> 
> (Sorry for complaining)
> Is it just me or do dates, milliseconds, GregorianCalendar completely
> confusing?

It is calendars that are confusing. The classes that deal with this topic
merely reflect the true complexity of human calendars.

> 
> I needed to build a simple JSP that displays a simple countdown for an
> election.
> It should show how many days untill elections start.
> During elections it should show how many days are left to vote, and when
> the election closingdate is over it should say: elections are passed.
> 
> This took me 4 hours and a lot of frustration. the API wasn't really a
> help either.
> I came up with the following huge script. (at the end)
> I code such things in PHP on 3 lines...
> 
> I was just wondering: Am I missing something completely or is working with
> dates really confusing?

Yes. :)

> (Like the double getTime().getTime() constructions.)
> 
> What is your experience?

Here's my experience (not really that different from your own):

// CalendarCountdown.java

import java.util.GregorianCalendar;

public class CalendarCountdown {
   
   public static void main(String args[])
   {
      final long millisToDays = 86400000;
      GregorianCalendar today = new GregorianCalendar();
      // remember: months are numbered 0 - 11 in this class
      // GregorianCalendar(year, month-1, day of month)
      GregorianCalendar electionDay = new GregorianCalendar(2004,10,15);
      long days = (electionDay.getTimeInMillis() - today.getTimeInMillis())
/ millisToDays;
      String s = (days > 0)?"It is " + days + " days until election day."
      :(days == 0)?"Election day is today."
      :"Election day has passed.";
      System.out.println(s);
      
   }
}

-- 
Paul Lutus
http://www.arachnoid.com

Jacob wrote:

> Erwin Moller wrote:
> 
>> (Sorry for complaining)
>> Is it just me or do dates, milliseconds, GregorianCalendar completely
>> confusing?
> 
> You're allowed to complain!
> 
> It's not a mess as it contains a lot of complex logic to handle
> the complicated world of calendars, days and time, but the API
> is not suitable for the many simple cases like yours.
> 
> The main problem (I think) is that dates and times are mixed into
> the same class: java.util.Date.

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

Paul Lutus wrote:
> Jacob wrote:
> 
> 
>>Erwin Moller wrote:
>>
>>
>>>(Sorry for complaining)
>>>Is it just me or do dates, milliseconds, GregorianCalendar completely
>>>confusing?
>>
>>You're allowed to complain!
>>
>>It's not a mess as it contains a lot of complex logic to handle
>>the complicated world of calendars, days and time, but the API
>>is not suitable for the many simple cases like yours.
>>
>>The main problem (I think) is that dates and times are mixed into
>>the same class: java.util.Date.
> 
> 
> 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.

java.util.Date as such is not deprecated (as I know of),
though many of its access functions are.
And I am not sure using a GregorianCalendar instead
improves matters? :-)

Jacob wrote:

/ ...

>> 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.
> 
> java.util.Date as such is not deprecated (as I know of),
> though many of its access functions are.

Because so many of Date's methods are deprecated (23 altogether), that's
saying the same thing.

> And I am not sure using a GregorianCalendar instead
> improves matters? :-)

Yes, of course it does. GregorianCalendar was written to address the
deficiencies in Date. Unless by "matters" you mean making things simpler
for the programmer.

-- 
Paul Lutus
http://www.arachnoid.com

Erwin Moller wrote:

> I was just wondering: Am I missing something completely or is working with 
> dates really confusing?
> (Like the double getTime().getTime() constructions.)
> 
> What is your experience?

Java's date/time API are confusing, inconsistent, and sometimes 
counter-intuitive.  I have found that the API docs do help me, but they 
can't solve the underlying problem that the API themselves are not well 
designed.  The API and docs can be used fairly easily once one has 
become familiar with them, however.

> <%@ page import="java.util.Date" %>
> <%@ page import="java.util.Calendar" %>
> <%@ page import="java.text.SimpleDateFormat" %>
> <%@ page import="java.util.Date" %>
> <%@ page import="java.util.Calendar" %>
> <%@ page import="java.util.GregorianCalendar" %>

You import Date and Calendar twice, but don't explicitly use either one. 
  You import SimpleDateFormat but don't use it at all.  You only need 
the last (GregorianCalendar) import.

> <%
>     // this file represents a countdontcounter
> 
>     // We have 2 dates:
>     // startElectionDate = startdate of elections
>     // endElectionDate = enddate of elections
>     
>     // format them: (yyyy,mm,dd)
>     // warning, month is 0 based! 0 = januari, 1 = februari
>     GregorianCalendar startElectionGregorianCalendar = new 
> GregorianCalendar(2004, 7 , 2);
>     GregorianCalendar endElectionGregorianCalendar = new 
> GregorianCalendar(2004, 8, 1);    

Your code would be clearer (and you wouldn't need the warning comment) 
if you used the month number static constants declared in Calendar 
instead of plain int arguments.

>     GregorianCalendar nowGregorianCalendar = new GregorianCalendar();

You only use that calendar to get the current time, so you could just as 
well say:

     long now = System.currentTimeMillis();

>     long mssecInADay = (1000*60*60*24);
>     
>     // if <0 already passed
>     double dDaysToStartDate = (double) 
> (startElectionGregorianCalendar.getTime().getTime() -  
> nowGregorianCalendar.getTime().getTime()) / mssecInADay;

Instead of .getTime().getTime() you might want to use .getTimeInMillis()

>     // if <0 already passed
>     double dDaysToEndDate = (double) 
> (endElectionGregorianCalendar.getTime().getTime() -   
> nowGregorianCalendar.getTime().getTime()) / mssecInADay;
>     
>     String strDisplay = "";
>     if (dDaysToStartDate >0){
>         strDisplay = ""+dDaysToStartDate+" days untill elections.";
>     } else {
>         if (dDaysToEndDate >0) {
>           strDisplay = "Elections running. you have "+dDaysToEndDate+" days 
> to vote left.";
>         } else {
>           strDisplay = "Voting is over.";
>         }
>     }
> %>
> <!-- Start countdown -->
>       <%= strDisplay %>
> <!-- End countdown -->

My earlier comments notwithstanding, that doesn't seem particularly big 
or complicated.


John Bollinger
jobollin@indiana.edu

Paul Lutus wrote:
> Jacob wrote:
> 
> 
>>>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.
>>
>>java.util.Date as such is not deprecated (as I know of),
>>though many of its access functions are.
> 
> 
> Because so many of Date's methods are deprecated (23 altogether), that's
> saying the same thing.
> 

Actually it is not the same thing.

As mentioned in the javadoc comments of the Date class, it is only the methods
of Date that perform the conversion from/to the human readable year/month....
(and the Locale specific stuff that takes care of TimeZones and daylight saving)
that have been deprecated in favour of the Calendar class. For performing any
relative time computations as what the OP wanted, Date is what he would really
need to use. (The getTimeInMillis() function does use a Date object internally
and is only a shortcut to calendar.getTime().getTime()).

It is another matter that without the deprecated functions, the Date class is
simply a wrapper around a longint - but it is certainly not deprecated, and its
use is essential for several applications (like date formatting, SQL date/time
functions etc)

BK

Babu Kalakrishnan wrote:

> Paul Lutus wrote:
>> Jacob wrote:
>> 
>> 
>>>>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.
>>>
>>>java.util.Date as such is not deprecated (as I know of),
>>>though many of its access functions are.
>> 
>> 
>> Because so many of Date's methods are deprecated (23 altogether), that's
>> saying the same thing.
>> 
> 
> Actually it is not the same thing.

Because Date's remaining non-deprecated methods have some residual
usefulness, I guess I agree. But if it were a deprecation Olypmpics, Date
would lose (or win, depending on your outlook).

-- 
Paul Lutus
http://www.arachnoid.com

Paul Lutus wrote:
> Because Date's remaining non-deprecated methods have some residual
> usefulness, I guess I agree. But if it were a deprecation Olypmpics, Date
> would lose (or win, depending on your outlook).

In my view, it's not so much that Date has remaining useful methods (it 
really doesn't do much versus long), but that it's used in the standard 
API as a marker that a parameter represents a date/time, versus some 
other kind of number.  There's no indication that it's use as such 
should be discouraged in other code as well, and I consider it good form 
versus declaring a lot of parameters of type long, or certainly versus 
writing your own wrapper for a date/time to compensate.

It speaks volumes, for example, that the replacement for all of that 
lost functionality of the Date class is now provided by classes that 
can't reasonable be used without Date (java.text.DateFormat and 
java.util.Calendar, for example).

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Chris Smith wrote:

> Paul Lutus wrote:
>> Because Date's remaining non-deprecated methods have some residual
>> usefulness, I guess I agree. But if it were a deprecation Olypmpics, Date
>> would lose (or win, depending on your outlook).
> 
> In my view, it's not so much that Date has remaining useful methods (it
> really doesn't do much versus long), but that it's used in the standard
> API as a marker that a parameter represents a date/time, versus some
> other kind of number.

Yes, I should have mentioned that. It's the same issue with StringTokenizer,
another class "in trouble" so to speak, but because of its presence in
existing code, there can be no question of getting rid of it. It's the
legacy issue.

>  There's no indication that it's use as such
> should be discouraged in other code as well, and I consider it good form
> versus declaring a lot of parameters of type long, or certainly versus
> writing your own wrapper for a date/time to compensate.

I concur, and I should have thought of the point you are making.

> It speaks volumes, for example, that the replacement for all of that
> lost functionality of the Date class is now provided by classes that
> can't reasonable be used without Date (java.text.DateFormat and
> java.util.Calendar, for example).

Let's face it -- it's an inelegant but necessary repair job. It reminds me
of the very annoying total overhaul of the handling of actions between (if
memory serves) 1.0 and 1.1. The original scheme just wasn't thought out
very well. Same with Date, and I have had to rewrite a lot of my early code
to accommodate the changes in both cases (I always take "deprecated" to be
a synonym for "remove or eventually lose").

-- 
Paul Lutus
http://www.arachnoid.com

John C. Bollinger wrote:
> Erwin Moller wrote:
> 
>> I was just wondering: Am I missing something completely or is working 
>> with dates really confusing?
>> (Like the double getTime().getTime() constructions.)
>>
>> What is your experience?

It is many things:
1. Messy because our calendar is a real kludge.
2. Messy because daylight savings adds another level of complexity.
2. Date and Calendar contain some things inhereted from Unix date manipulation: 
0=January, the use of name getTime() to get the things which is actually a Date+Time
3. You have to understand that Date IS still intended to be used to
HOLD a binary time value while CALCULATIONS on dates are done with a
calendar.  One is a token pattern, the other a strategy pattern, but
not entirely.

4. java.util.Calendar is incomplete for many useful calculations.

Given all that, it is no wonder you'd get it wrong and you did,
particularly since you didn't try very many representative times
to see if they work, because it breaks on some obvious ones.

That is one reason you should not use scriptlets but instead
write a class which returns the number of delta days.  Then
try the days right around the target date and see what happens.

So first let's write a testable class using your algorithm.

import java.util.Calendar;
import java.util.GregorianCalendar;

/**
  * @author Paul Hill
  * @since  Aug 19, 2004
  */
public class Election {
     private static final int MILLISECSPERDAY = (1000*60*60*24);
     private GregorianCalendar startElection;

     private GregorianCalendar endElection;

     public Election() {
         startElection = new GregorianCalendar(2004, Calendar.AUGUST, 2);
         endElection = new GregorianCalendar(2004, Calendar.SEPTEMBER, 1);
     }

     public String getDayStatement() {

         GregorianCalendar now = new GregorianCalendar();

         return getDayStatement(now);
     }

     public double getDaysToStart(GregorianCalendar now) {
         double dDaysToStartDate = (double)(startElection.getTime().getTime() -
              now.getTime().getTime()) / MILLISECSPERDAY;

         return dDaysToStartDate;
     }

     public double getDaysToEnd(GregorianCalendar now) {
         double dDaysToEndDate = (double)(endElection.getTime().getTime() -
			now.getTime().getTime()) / MILLISECSPERDAY;
         return dDaysToEndDate;
     }
}

**************************************************
Then a JUnit class to test it.  Just look at the 3 asserts at the bottom.
**************************************************
import junit.framework.TestCase;

/**
  * @author Paul Hill
  * @since  Aug 19, 2004
  */
public class ElectionTest extends TestCase {
     public ElectionTest(String name) {
         super(name);
     }
     public static void main(String[] args) {
         junit.textui.TestRunner.run(ElectionTest.class);
     }

     public void testSomeDays( ) {
         Election e = new Election();
         assertEquals( 0d, e.getDaysToStart( new GregorianCalendar( 2004, 
Calendar.AUGUST, 2 )), 0.1d );
         assertEquals( 0d, e.getDaysToEnd( new GregorianCalendar( 2004, 
Calendar.SEPTEMBER, 1 )), 0.1d );
         /// sometime the day before
         assertEquals( 1d, e.getDaysToStart( new GregorianCalendar( 2004, 
Calendar.AUGUST, 1, 17, 0, 0 )), 0.1d );
     }
}
***************************************************************************
Boink! The third assert fails to find that a date in the evening the day before 
the election should be reported as 1 day to go.  Instead I got:

There was 1 failure:
1) testSomeDays(ElectionTest)junit.framework.AssertionFailedError: 
expected:<1.0> but was:<0.2916666666666667>

****************************************************************************
Why?  Because you need to correctly convert to days to drop any fractions
AND THEN SUBTRACT
************************************************************************
Let me help you:

Try this class:
import java.util.GregorianCalendar;
import java.util.Calendar;

/**
  * @author Paul Hill
  */
public class FAQCalendar extends GregorianCalendar {
     /**
      * All minutes have this many milliseconds except the last minute of the 
day on a day defined with
      * a leap second.
      */
     public static final long MILLISECS_PER_MINUTE = 60*1000;

     /**
      * Number of leap seconds per hour, except when a leap second is inserted.
      */
     public static final long MILLISECS_PER_HOUR   = 60*MILLISECS_PER_MINUTE;

     /**
      * Number of leap seconds per day expect on
      * <BR/>1. days when a leap second has been inserted, e.g. 1999 JAN  1.
      * <BR/>2. Daylight-savings spring forward or fall back days.
      */
     protected static final long MILLISECS_PER_DAY = 24*MILLISECS_PER_HOUR;

     public FAQCalendar() {
         super();
     }
     public FAQCalendar( int y, int m, int d ) {
         super( y, m, d );
     }

     public FAQCalendar( int y, int m, int d, int h, int min, int s ) {
         super( y, m, d, h, min, s );
     }
     /**
      * @return Day number where day 0 is 1/1/1970, as per the Unix/Java 
date/time epoch.
      */
     public long getUnixDay() {
         long offset = get(Calendar.ZONE_OFFSET) + get(Calendar.DST_OFFSET);
         long day = (long)Math.floor( (double)(getTime().getTime() + offset ) / 
((double)MILLISECS_PER_DAY) );
         return day;
     }
}
*************************************************
Then you can rewrite the Election class to use this class that knows
how to correctly find the day.
*************************************************
import java.util.GregorianCalendar;

/**
  * This should really be a rewrite, but I have subclassed to not repeat
  * what was shown above.
  * @author Paul Hill
  * @since  Aug 19, 2004
  */
public class Election2 extends Election {
     private FAQCalendar startElection;
     private FAQCalendar endElection;

     public Election2() {
         super();
     }

     public double getDaysToStart(GregorianCalendar now) {
         FAQCalendar c = new FAQCalendar();
         c.setTime( now.getTime() );

         double dDaysToStartDate = startElection.getUnixDay() -  c.getUnixDay(); 

         return dDaysToStartDate;
     }

     public double getDaysToEnd(GregorianCalendar now) {
         FAQCalendar c = new FAQCalendar();
         c.setTime( now.getTime() );
         double dDaysToEndDate = endElection.getUnixDay() -  c.getUnixDay();
         return dDaysToEndDate;
     }
}
******************************************************
If you write the above test to try using this class you find it does
the right things.
******************************************************

HTH,
-Paul

p.s. Your algorithm also suffers from Daylight savings problems.

Paul Lutus wrote:

>(I always take "deprecated" to be
> a synonym for "remove or eventually lose").

But just because a bunch of methods are deprecated
doesn't mean the class has no use; Date to hold a binary date-times,
Calendar to manipulate date-times.

-Paul

Paul Lutus wrote:
> > In my view, it's not so much that Date has remaining useful methods (it
> > really doesn't do much versus long), but that it's used in the standard
> > API as a marker that a parameter represents a date/time, versus some
> > other kind of number.
> 
> Yes, I should have mentioned that. It's the same issue with StringTokenizer,
> another class "in trouble" so to speak, but because of its presence in
> existing code, there can be no question of getting rid of it. It's the
> legacy issue.

Hmm... I'm still not sure if we're saying the same thing.  We might be, 
but I'm unsure.  What I mean is that using java.util.Date is in no way a 
"legacy" thing at all.  I would happily design new APIs that take Date 
objects as parameters or return them as results, though obviously the 
deprecated APIs are to be avoided.

In essence, if I were asked to redesign the Java core API right now with 
no backward compatibility issues, I still think there'd be a use for a 
class that encapsulates a date/time in a strongly typed package, so I 
would include the Date class and use it every bit as much as it is now.  
(That isn't to say that I wouldn't make some additional changes, such as 
making instances of Date immutable, but that's a different matter.)

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Chris Smith wrote:

> Paul Lutus wrote:
>> > In my view, it's not so much that Date has remaining useful methods (it
>> > really doesn't do much versus long), but that it's used in the standard
>> > API as a marker that a parameter represents a date/time, versus some
>> > other kind of number.
>> 
>> Yes, I should have mentioned that. It's the same issue with
>> StringTokenizer, another class "in trouble" so to speak, but because of
>> its presence in existing code, there can be no question of getting rid of
>> it. It's the legacy issue.
> 
> Hmm... I'm still not sure if we're saying the same thing.  We might be,
> but I'm unsure.  What I mean is that using java.util.Date is in no way a
> "legacy" thing at all.

My legacy remark was more about StringTokenizer. Clearly the truncated Date
class has a remaining vital purpose.

> I would happily design new APIs that take Date
> objects as parameters or return them as results, though obviously the
> deprecated APIs are to be avoided.
> 
> In essence, if I were asked to redesign the Java core API right now with
> no backward compatibility issues, I still think there'd be a use for a
> class that encapsulates a date/time in a strongly typed package, so I
> would include the Date class and use it every bit as much as it is now.
> (That isn't to say that I wouldn't make some additional changes, such as
> making instances of Date immutable, but that's a different matter.)

Well, given that hypothetical condition (no legacy burdens and a free hand)
I think the Date class and the GregorianCalendar class would be merged into
a single class that handles what is left of Date and all of the present
GregorianCalendar. There is a lot of commmonality of purpose, and even some
overlap in function (like the default GregorianCalendar constructor that
produces an object set to the current time, exactly as the default Date
constructor does).

At this point, and seeing the blurring of function between the classes, it
is reasonable to ask (granted the hypothetical power described above)
whether the two classes are really distinct in purpose any more.

Speaking hypothetically, of course.

-- 
Paul Lutus
http://www.arachnoid.com

Paul Lutus wrote:

> There is a lot of commmonality of purpose, and even some
> overlap in function (like the default GregorianCalendar constructor that
> produces an object set to the current time, exactly as the default Date
> constructor does).

So because two things start with a similar initial value they have overlapping
purpose?  Sorry I don't see that.

> At this point, and seeing the blurring of function between the classes, 

Really what does the Date class do which is a repeat of what is in
a Calendar?  The only thing Date does is that it gives and takes a binary 
number. Yes, Calendar does that because it delegates to a Date object!

> it
> is reasonable to ask (granted the hypothetical power described above)
> whether the two classes are really distinct in purpose any more.

Yes, a Date HOLDS not much more than a binary value (the other field, if it is 
still there is transient) while the other class, GregorianCalendar has a binary
value in it, HELD IN a DATE object, but also has an array of fields that are 
that binary value broken up, plus it holds a timezone, plus ...

The point is one is a simple representation, the other is (almost) everything 
needed to manipulate dates.  One is used to push around a datetime stamp 
(assuming you don't need it to know the timezone) while the other would be a 
really stupid thing to push down a wire to communicate some moment.

> Speaking hypothetically, of course.

If Chris rewrites the Date and Calendar, one
will be a token which will be the smallest representation of a date-time
and the other will be something to break one of those date-times up into a 
myriad fields and helps with calculations upon these fields.  Two different 
beasts; please keep them straight.

(Gregorian)Calendar is NOT a new and improved Date, it is an encapsulation of
how a moment in time is converted to the fields of a particular calendar.
Consider how you would make the One-True DateTimeCalendar class which could
handle different Calendars.  A Calendar algorithm is not a Date(Time) in the
IS-A OO sense.

-Paul

P.Hill wrote:

> Paul Lutus wrote:
> 
>> There is a lot of commmonality of purpose, and even some
>> overlap in function (like the default GregorianCalendar constructor that
>> produces an object set to the current time, exactly as the default Date
>> constructor does).
> 
> So because two things start with a similar initial value they have
> overlapping
> purpose?  Sorry I don't see that.

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

> 
>> At this point, and seeing the blurring of function between the classes,
> 
> Really what does the Date class do which is a repeat of what is in
> a Calendar?

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.

> The only thing Date does is that it gives and takes a binary
> number. Yes, Calendar does that because it delegates to a Date object!
> 
>> it
>> is reasonable to ask (granted the hypothetical power described above)
>> whether the two classes are really distinct in purpose any more.
> 
> Yes, a Date HOLDS not much more than a binary value (the other field, if
> it is still there is transient) while the other class, GregorianCalendar
> has a binary value in it, HELD IN a DATE object, but also has an array of
> fields that are that binary value broken up, plus it holds a timezone,
> plus ...

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, and granted the very hypothetical
nature of this entire discussion. As I pointed out, thay already share a
constructor, for all practical purposes.

-- 
Paul Lutus
http://www.arachnoid.com

Paul Lutus wrote:
> Well, given that hypothetical condition (no legacy burdens and a free hand)
> I think the Date class and the GregorianCalendar class would be merged into
> a single class that handles what is left of Date and all of the present
> GregorianCalendar. There is a lot of commmonality of purpose, and even some
> overlap in function (like the default GregorianCalendar constructor that
> produces an object set to the current time, exactly as the default Date
> constructor does).

And what of those places that don't use the Gregorian calendar? I think 
the separation between Date and Calendar is correct. I would change the 
Date(String) constructor and toString() methods to use ISO8601 format.

Mark Thornton

Hi all,

Thanks a lot for all your responses!
Many were valuable for me.
I learned a lot by just watching you all discussing the subject. :-)

It is clear to me now that actual complexity lies foremost in the fact that 
calendars themself are really complex in the real world. So any 
implementation must reflext this complexity (or try to hide it).

And yes, My samplecode was importing too much and even double. 
Sloppy code, created with some frustration. 
I corrected it of course. (Thanks John Bollinger)

I also understand it is easy for me to look at the API now and say they 
should have done a better job.
In the real world you have to deal with backwards compatibility. Old code 
new versions of Java 'should' support.

I have 1 question left:
Why didn't Sun just release a better version of Date? (the GoodDate class or 
something)
Or should I consider GregorianCalendar as the improved version?

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

(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);

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

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

It has been many years now since I coded VBscript, but if memory serves me 
well those VB guys had functions that did this. Handy. 
(If I sound lazy and spoiled, sorry for that!)

Thanks for your time!

Regards,
Erwin Moller

Paul Lutus wrote:
> 
> 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, and granted the very hypothetical
> nature of this entire discussion. As I pointed out, thay already share a
> constructor, for all practical purposes.
> 

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.
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). Trying to use a Calendar object 
which is much more complex beast for this is certainly overkill.

Also a far as I can remember, the Calendar class does not use a Date object or
any of its methods for anything (other than of course for its methods that take
a Date as an argument or return a Date object). On the other hand, the Date
class does use a Calendar object internally to support the deprecated methods -
so it is no longer lightweight if you use its deprecated methods.

BK

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
http://www.arachnoid.com

Mark Thornton wrote:

> Paul Lutus wrote:
>> Well, given that hypothetical condition (no legacy burdens and a free
>> hand) I think the Date class and the GregorianCalendar class would be
>> merged into a single class that handles what is left of Date and all of
>> the present GregorianCalendar. There is a lot of commmonality of purpose,
>> and even some overlap in function (like the default GregorianCalendar
>> constructor that produces an object set to the current time, exactly as
>> the default Date constructor does).
> 
> 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.

-- 
Paul Lutus
http://www.arachnoid.com

Erwin Moller wrote:
> // 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

Babu Kalakrishnan wrote:

> Paul Lutus wrote:
>> 
>> 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, and
>> granted the very hypothetical nature of this entire discussion. As I
>> pointed out, thay already share a constructor, for all practical
>> purposes.
>> 
> 
> 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.

-- 
Paul Lutus
http://www.arachnoid.com

Paul Lutus wrote:
> 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

Paul Lutus wrote:

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

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

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

-- 
Paul Lutus
http://www.arachnoid.com

Paul Lutus wrote:
 > 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

Paul Lutus wrote:

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

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

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

Erwin Moller wrote:
> 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

Paul Lutus wrote:
> 
> 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 ?

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

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

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

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

P.Hill wrote:

> Paul Lutus wrote:
> 
>> 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.

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.

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

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

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.

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

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
http://www.arachnoid.com

P.Hill wrote:

> Erwin Moller wrote:
>> 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.

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
http://www.arachnoid.com

P.Hill wrote:

> Paul Lutus wrote:
>  > I think they created GregorianCalendar to avoid
>> confusion and make a clean break with the compromised past.
> 
> 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
http://www.arachnoid.com

Babu Kalakrishnan wrote:

> Paul Lutus wrote:
>> 
>> 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 ?

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.

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

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

-- 
Paul Lutus
http://www.arachnoid.com

Paul Lutus wrote:
> 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

Paul Lutus wrote:

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

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

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*

P.Hill wrote:

> Paul Lutus wrote:
> 
>> 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.

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

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.

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

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

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.

-- 
Paul Lutus
http://www.arachnoid.com

Paul Lutus wrote:
> Babu Kalakrishnan wrote:
 >
>> 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.
> 
> 

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

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

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

Babu Kalakrishnan wrote:

 /...

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

Well, this is now way too hypothetical to even to try to convert into
something useful.

BTW your having included my SIG line in the midst of your quote of me caused
the remainder of the quote to be truncated in this reply. I have
hand-included it:

> My (rather limited) understanding of the English language tells
> me that the
> indirect sentence "people are being advised"

It is more indirect than your quote of it. I originally said "it appears
people are being advised," and a copy of the original appears above in this
message. That's pretty hypothetical.

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

My "no one offered this advice" remark referred only to the contents of this
thread, not the outside world. But, as I said, this is heaping
hypotheticals on hypotheticals. There really is no point to this. It's too
far away from anything useful now. I think you agree.

-- 
Paul Lutus
http://www.arachnoid.com

Cid <cid@noSuchAddress.no> coughed up the following:
> 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.

I have been advocating this for 2 decades now.  Time zones are dumb, serve
no purpose that I can see, and cause lots of conversion grief.  If we're
gonna be "one-world", we might as well have "one-clock".


> Also:
> - flat tax

To keep the libbies from throwing a hissy fit {duck}, I'd say that I'd
accept a graduated tax curve like we have now, but remove all the loopholes.
The tax rate of x% would mean that.  Deductions rob peter to pay paul.  The
best alternative to all this is /maybe/ a federal sales tax under the
proviso that it starts precisely when the income tax vanishes completely.


> - Subway will put veggies on top meat like a normal God-fearing
> sandwhich

lol.


> - car engines run on clean burning hydrogen, cold fusion, or good
> intentions

Fine by me.  The last one though is the scarcest of all the resources.


> - Israel becomes a world historic park and nobody from any country is
> allowed to live there permanantly, but can visit (sans weapons)

I'm not sure just /what/ the heck to do with Israel.  New Hampshire in a
north american continent of hatred and suicide bombings?  One side is gonna
have to obliterate the other.  {shrug}


> - Schwarzeneger to be made president 2004 on condition that he wear
> leather and sunglasses during all speeches.

There's actually something to this.  LOL.  Remember that we now have the USS
Ronald Reagan.  From name alone, positioning that thing 200 miles off of any
border will make anyone nervous.


>
> *Fleeeeeeeeeeeeeeeeeeeeeeeee*

I'll cover you.  go go go go go.......  Now what?  Arg!  Now I gotta
fleeeeeeeee.......


-- 
http://www.allexperts.com is a nifty way to get an answer to just about
/anything/.

Paul Lutus <nospam@nosite.zzz> coughed up the following:
> P.Hill wrote:
>> Paul Lutus wrote:

....[rip]...

into the abyss.....



-- 
http://www.allexperts.com is a nifty way to get an answer to just about
/anything/.

Thomas G. Marshall wrote:

> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>> P.Hill wrote:
>>> Paul Lutus wrote:
> 
> ...[rip]...
> 
> into the abyss.....

Very productive post. There was a time when people who couldn't follow a
thread kept it to themselves.

-- 
Paul Lutus
http://www.arachnoid.com

Paul Lutus wrote:

> > into the abyss.....
>
> Very productive post. There was a time when people who couldn't follow a
> thread kept it to themselves.

That would be back when knights fought dragons for the favours of fair maidens,
I presume ?

Or were you referring to the Fall of Man ?

    -- chris

Paul Lutus <nospam@nosite.zzz> coughed up the following:
> Thomas G. Marshall wrote:
>
>> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>>> P.Hill wrote:
>>>> Paul Lutus wrote:
>>
>> ...[rip]...
>>
>> into the abyss.....
>
> Very productive post. There was a time when people who couldn't
> follow a thread kept it to themselves.

lol.  I followed it alright.  Hence the post.  What a shock {sarcasm} that I
had to explain it to you.

-- 
Onedoctortoanother:"Ifthisismyrectalthermometer,wherethehell'smypen???"

Thomas G. Marshall wrote:

> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>> Thomas G. Marshall wrote:
>>
>>> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>>>> P.Hill wrote:
>>>>> Paul Lutus wrote:
>>>
>>> ...[rip]...
>>>
>>> into the abyss.....
>>
>> Very productive post. There was a time when people who couldn't
>> follow a thread kept it to themselves.
> 
> lol.  I followed it alright.

You mean, like your self-evident grasp of English spelling and grammar?

> Hence the post.  What a shock {sarcasm} that
> I had to explain it to you.

Some abyss. Compared to your scintillating posts and sense of internal
consistency, an abyss is a welcome alternative. Obviously speaking
hypothetically.

-- 
Paul Lutus
http://www.arachnoid.com

Paul Lutus <nospam@nosite.zzz> coughed up the following:
> Thomas G. Marshall wrote:
>
>> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>>> Thomas G. Marshall wrote:
>>>
>>>> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>>>>> P.Hill wrote:
>>>>>> Paul Lutus wrote:
>>>>
>>>> ...[rip]...
>>>>
>>>> into the abyss.....
>>>
>>> Very productive post. There was a time when people who couldn't
>>> follow a thread kept it to themselves.
>>
>> lol.  I followed it alright.
>
> You mean, like your self-evident grasp of English spelling and
> grammar?

What part of that statement bothers you?  If it's the word "alright", it's
non-standard /only/ as an adjective.


>
>> Hence the post.  What a shock {sarcasm} that
>> I had to explain it to you.
>
> Some abyss. Compared to your scintillating posts and sense of internal
> consistency, an abyss is a welcome alternative. Obviously speaking
> hypothetically.

-- 
It'salwaysbeenmygoalinlifetocreateasignaturethatendedwiththeword"blarphoogy"
..

Thomas G. Marshall wrote:

> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>> Thomas G. Marshall wrote:
>>
>>> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>>>> Thomas G. Marshall wrote:
>>>>
>>>>> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>>>>>> P.Hill wrote:
>>>>>>> Paul Lutus wrote:
>>>>>
>>>>> ...[rip]...
>>>>>
>>>>> into the abyss.....
>>>>
>>>> Very productive post. There was a time when people who couldn't
>>>> follow a thread kept it to themselves.
>>>
>>> lol.  I followed it alright.
>>
>> You mean, like your self-evident grasp of English spelling and
>> grammar?
> 
> What part of that statement bothers you?  If it's the word "alright", it's
> non-standard /only/ as an adjective.

There was a time, not very long ago, when it wasn't a word. None of this
will matter after a bit -- enough people will use "alright", a
lexicographer will notice, and Bob's your uncle. Assuming this hasn't
already happened.

You didn't notice "lol" as a possible candidate. It's an acronym, therefore
it should be in caps. But who cares? It would be somewhat ironic and
misleading if you possessed grammatical skills completely out of line with
your overall abilities.

-- 
Paul Lutus
http://www.arachnoid.com

Paul Lutus <nospam@nosite.zzz> coughed up the following:
> Thomas G. Marshall wrote:
>
>> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>>> Thomas G. Marshall wrote:
>>>
>>>> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>>>>> Thomas G. Marshall wrote:
>>>>>
>>>>>> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>>>>>>> P.Hill wrote:
>>>>>>>> Paul Lutus wrote:
>>>>>>
>>>>>> ...[rip]...
>>>>>>
>>>>>> into the abyss.....
>>>>>
>>>>> Very productive post. There was a time when people who couldn't
>>>>> follow a thread kept it to themselves.
>>>>
>>>> lol.  I followed it alright.
>>>
>>> You mean, like your self-evident grasp of English spelling and
>>> grammar?
>>
>> What part of that statement bothers you?  If it's the word
>> "alright", it's non-standard /only/ as an adjective.
>
> There was a time, not very long ago, when it wasn't a word. None of
> this will matter after a bit -- enough people will use "alright", a
> lexicographer will notice, and Bob's your uncle. Assuming this hasn't
> already happened.

So I guess YOU fucked up, and YOU don't know English grammar, even though
YOU were the one trying to pretend that you could insult me with my
(correct) usage of it.

Smooth.  Next time try acknowledging your mistakes instead of trying to
cover them up with hand waving.  People /might/ respect you then.


> You didn't notice "lol" as a possible candidate. It's an acronym,
> therefore it should be in caps. But who cares?

You were the one bringing up English grammar.  Not me.  I never claimed to
be using grammar correctly.  Not once.  But you thought you could blast me
with it, because you had nothing else to say.  And you don't own up to it?

Wow.  And not only can you not accept that you are wrong, but you try to
cover by saying that lol should be in caps?  You're making a fool out of
yourself (again).


> It would be somewhat
> ironic and misleading if you possessed grammatical skills completely
> out of line with your overall abilities.

Such a pathetic attempt to cover your own mistakes.

I tell you what paul, I'll give you want you seem to be begging for: a
killfile (again).  I would have kept you in it the first time around, but I
got a new system, and a blanked out killfile.  Congrats.  Say what you like
now...

<PLONK>

-- 
Whyowhydidn'tsunmakejavarequireanuppercaselettertostartclassnames....

Paul Hill,

Your algorithm to calculate the number of days between two
date-time-stamps is flawed.

If calculating the number of seconds between two times, should we ignore
the fractional number of seconds in the start and/or end times?  For
example, how many seconds are between 0:12:02.125 and 0:12:10.548 ?  Is it
8, 8.423, or 9?  Similar questions can be made at any level of unit.

Let's tackle leap seconds.  There is a complicated formula that specifies
when we will have 60, 61, or 62 seconds in a minute (we have not
experienced a 62 second minute since adopting the Gregorian Calendar, but
it is possible).  Since minutes have variable number of seconds, we cannot
do a simple divide and get the correct answer in all cases.

I believe I scratched the surface as to why a simple subtract followed by
division does not always work.

BTW, You could create a DateSpan class which would do all these
calculations for you (again, be sure to keep track of the TimeZone issues).

HTH,
La'ie Techie

"Erwin Moller"
<since_humans_read_this_I_am_spammed_too_much@spamyourself.com> wrote in
message news:41248cce$0$566$e4fe514c@news.xs4all.nl...
> Hi group,
>
> (Sorry for complaining

then don't

On Fri, 20 Aug 2004 17:06:05 -0400, Cid wrote:

> - car engines run on clean burning hydrogen, cold fusion, or good
> intentions

You can't be serious about hydrogen.  Pure hydrogen is too volatile to
store.  Unless our fuel stations pump pure H2O and cars separate the
hydrogen from the oxygen.  Any other trace elements would build up on the
pipes.  In this system, only oxygen with mall traces of hydrogen would be
released into the atmosphere.

La'ie Techie

Thomas G. Marshall wrote:

> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>> Thomas G. Marshall wrote:
>>
>>> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>>>> Thomas G. Marshall wrote:
>>>>
>>>>> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>>>>>> Thomas G. Marshall wrote:
>>>>>>
>>>>>>> Paul Lutus <nospam@nosite.zzz> coughed up the following:
>>>>>>>> P.Hill wrote:
>>>>>>>>> Paul Lutus wrote:
>>>>>>>
>>>>>>> ...[rip]...
>>>>>>>
>>>>>>> into the abyss.....
>>>>>>
>>>>>> Very productive post. There was a time when people who couldn't
>>>>>> follow a thread kept it to themselves.
>>>>>
>>>>> lol.  I followed it alright.
>>>>
>>>> You mean, like your self-evident grasp of English spelling and
>>>> grammar?
>>>
>>> What part of that statement bothers you?  If it's the word
>>> "alright", it's non-standard /only/ as an adjective.
>>
>> There was a time, not very long ago, when it wasn't a word. None of
>> this will matter after a bit -- enough people will use "alright", a
>> lexicographer will notice, and Bob's your uncle. Assuming this hasn't
>> already happened.
> 
> So I guess YOU fucked up, and YOU don't know English grammar,

NO, that would be your own mistake.

> even though
> YOU were the one trying to pretend that you could insult me with my
> (correct) usage of it.

It is not correct, and I can't believe even you can take that
interpretation. Dictionaries reflect how people use words, they do not
suggest correct usage. That is not their role.

-- 
Paul Lutus
http://www.arachnoid.com

Lāʻie Techie wrote:

> On Fri, 20 Aug 2004 17:06:05 -0400, Cid wrote:
> 
>> - car engines run on clean burning hydrogen, cold fusion, or good
>> intentions
> 
> You can't be serious about hydrogen.  Pure hydrogen is too volatile to
> store.

Tell NASA. They store it all the time. I am not saying it is easy, but it is
practical.

The real propblem with hydrogen is it's not actually a source of energy in
the sense the petrochemicals are, instead it is a transfer medium. The
hydrogen must be split away from water, and the energy to do the splitting
is not quite recovered when the hydrogen is later burned.

> Unless our fuel stations pump pure H2O and cars separate the
> hydrogen from the oxygen.

Okay, it seems you don't understand the technology. A closed system that
split water into hydrogen and oxygen, then burned the hydrogen, would have
to acquire energy from outside the system to make up for the losses in the
conversions.

-- 
Paul Lutus
http://www.arachnoid.com

Lāʻie Techie wrote:

> Paul Hill,
> 
> Your algorithm to calculate the number of days between two
> date-time-stamps is flawed.

Not if the point is to determine the number of integral days. And that was
the stated goal.

> 
> If calculating the number of seconds between two times, should we ignore
> the fractional number of seconds in the start and/or end times?  For
> example, how many seconds are between 0:12:02.125 and 0:12:10.548 ?  Is it
> 8, 8.423, or 9?  Similar questions can be made at any level of unit.

And each of these questions has a trivial answer.

> 
> Let's tackle leap seconds.

A trivial adjustment, but not necessary for this task.

-- 
Paul Lutus
http://www.arachnoid.com

Liz wrote:

> 
> "Erwin Moller"
> <since_humans_read_this_I_am_spammed_too_much@spamyourself.com> wrote in
> message news:41248cce$0$566$e4fe514c@news.xs4all.nl...
>> Hi group,
>>
>> (Sorry for complaining
> 
> then don't

??
Liz?
What do you want to accomplish by this posting?
Humor maybe? I hope so.

Did you see the whole discussion?
Even if you read it superficially, you'll notice that we have a lot of 
different opinions.
It is complicated stuff.
When I write in a posting "Sorry for complaining" it is ment as an 
introduction for (possible stupid sounding) questions like: "Is it just me 
or do dates, milliseconds, GregorianCalendar completely confusing?"

What is your angle?
Did you write the code for Sun or something and are insulted by the fact 
some don't get it?
I do not understand the point of your posting.

Regards,
Erwin Moller

La'ie Techie wrote:

> Let's tackle leap seconds.  There is a complicated formula that specifies
> when we will have 60, 61, or 62 seconds in a minute

Is there ?  My understanding is that leap seconds are introduced ad-hoc.
Perhaps there's a mixture of scheduled (by a formula) leap seconds, and ad-hoc
ones, but there is a need for the second category since the length of the "day"
drifts in an unpredictable way (chaotic ?) if measured with sufficient
accuracy.

    -- chris

Chris Uppal wrote:

> La'ie Techie wrote:
> 
> 
>>Let's tackle leap seconds.  There is a complicated formula that specifies
>>when we will have 60, 61, or 62 seconds in a minute
> 
> 
> Is there ?  My understanding is that leap seconds are introduced ad-hoc.

Yes, that is true.  There is no formula.

-Paul

Paul Lutus wrote:
> The real propblem with hydrogen is it's not actually a source of energy in
> the sense the petrochemicals are, instead it is a transfer medium. The
> hydrogen must be split away from water, and the energy to do the splitting
> is not quite recovered when the hydrogen is later burned.

Really the same thing, except that in the case of petrochemicals, the
storing of energy in an easily-burnable substance has already been done by
Mother Nature over the course of millions of years...

Michael Borgwardt wrote:

> Paul Lutus wrote:
>> The real propblem with hydrogen is it's not actually a source of energy
>> in the sense the petrochemicals are, instead it is a transfer medium. The
>> hydrogen must be split away from water, and the energy to do the
>> splitting is not quite recovered when the hydrogen is later burned.
> 
> Really the same thing, except that in the case of petrochemicals, the
> storing of energy in an easily-burnable substance has already been done by
> Mother Nature over the course of millions of years...

Yep, which makes us think it's somehow free. :)

-- 
Paul Lutus
http://www.arachnoid.com

On Mon, 23 Aug 2004 14:21:01 -0700, Paul Lutus wrote:
> Michael Borgwardt wrote:

>> ...in the case of petrochemicals, the
>> storing of energy in an easily-burnable substance has already been done by
>> Mother Nature over the course of millions of years...
> 
> Yep, which makes us think it's somehow free. :)

The fact that non-replenishable (in scales of 
a human lifetime) petrol/gas generally sells 
for less than the price of an equivalent
amount of milk does not help that any.   :-/

-- 
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology

Erwin Moller wrote:
> Hi group,
> 
> (Sorry for complaining)
> Is it just me or do dates, milliseconds, GregorianCalendar completely 
> confusing? 

Apparently so, judging from the arguments that can erupt over such calculations.
In the interest of trying to avoid having to explain this yet again to another 
person who thinks they know the answer and trying to point out that
( day1Milliseconds - day2Milliseconds ) / MILLISECONDS_PER_DAY is NOT the 
correct answer for many values of day1 and day2 I suggest you, the
reader interested in this problem, see:
http://www.xmission.com/~goodhill/dates/deltaDates.html

If you have any suggestions for improvements to the article or code, please let 
me know.

-Paul Hill

P.Hill <goodhill.REMOVE@xmissionREMOVE.com> coughed up the following:
> Erwin Moller wrote:
>> Hi group,
>>
>> (Sorry for complaining)
>> Is it just me or do dates, milliseconds, GregorianCalendar completely
>> confusing?
>
> Apparently so, judging from the arguments that can erupt over such
> calculations. In the interest of trying to avoid having to explain
> this yet again to another person who thinks they know the answer and
> trying to point out that ( day1Milliseconds - day2Milliseconds ) /
> MILLISECONDS_PER_DAY is NOT the correct answer for many values of
> day1 and day2 I suggest you, the
> reader interested in this problem, see:
> http://www.xmission.com/~goodhill/dates/deltaDates.html
>
> If you have any suggestions for improvements to the article or code,
> please let me know.
>
> -Paul Hill


Curious: On all machine, in all locales, is the progression of java
milliseconds guaranteed to be linear?


-- 
"So I just, uh... I just cut them up like regular chickens?"
"Sure, just cut them up like regular chickens."

Thomas G. Marshall wrote:
> Curious: On all machine, in all locales, is the progression of java
> milliseconds guaranteed to be linear?

What do you mean with "linear"?

Michael Borgwardt <brazil@brazils-animeland.de> coughed up the
following:
> Thomas G. Marshall wrote:
>> Curious: On all machine, in all locales, is the progression of java
>> milliseconds guaranteed to be linear?
>
> What do you mean with "linear"?


(?)

Are there any jump discontinuities or ramping up or ramping down to
accommodate changes in leap seconds, etc., for the odd locale?  Or is this
always true:

    java end millis - java start millis == real world end millis - real
world start millis

Given an arbitrary start and end, and an arbitrary locale.



-- 
Everythinginlifeisrealative.Apingpongballseemssmalluntilsomeoneramsitupyourn
ose.

Thomas G. Marshall wrote:

> Michael Borgwardt <brazil@brazils-animeland.de> coughed up the
> following:
>> Thomas G. Marshall wrote:
>>> Curious: On all machine, in all locales, is the progression of java
>>> milliseconds guaranteed to be linear?
>>
>> What do you mean with "linear"?
> 
> 
> (?)
> 
> Are there any jump discontinuities or ramping up or ramping down to
> accommodate changes in leap seconds, etc., for the odd locale?  Or is this
> always true:
> 
>     java end millis - java start millis == real world end millis - real
> world start millis
> 
> Given an arbitrary start and end, and an arbitrary locale.

Mr. Hill's earlier argument is that there are things about calendars that no
existing class accomodates. This is an easy argument to make. But the fact
is that one can get self-consistent results easily from GregorianCalendar
objects from different locations, assuming the machines' clocks and time
zones are set correctly.

"Self-consistent" only means the results agree with each other, not that
they agree with someone's arbitrary choice of reference frame. For example,
did you know that the clocks on board the GPS satellites must be made to
run at a different rate (a difference of microseconds) than those on the
ground, for relativistic reasons?

The are any number of such special reference frames, but for everyday
purposes, you can subtract two millisecond values in Java and get something
useful and consistent.

-- 
Paul Lutus
http://www.arachnoid.com

Thomas G. Marshall wrote:
> Are there any jump discontinuities or ramping up or ramping down to
> accommodate changes in leap seconds, etc., for the odd locale?

This really has nothing to do with Java and everything to do with how the
underlying operating system implements its clock in regard to
leap seconds, daylight savings switches, etc.

Usually, this will result in sudden leaps of clock time, e.g. when
the clock is adjusted by a Network Time Protocol client. Of course,
the same thing happens when a user adjusts the time manually.

Another notable fact is that common OS's clocks are coarser than
the millisecond precision assumed by java, so the time will appear
to progress in little jumps of about 10 milliseconds

On Tue, 24 Aug 2004 17:32:07 -0700, P.Hill wrote:

> http://www.xmission.com/~goodhill/dates/deltaDates.html
> 
> If you have any suggestions for improvements to the article or code, please let 
> me know.

http://www.xmission.com/~goodhill/dates/deltadates.html

(URL's with upper case are a hassle..)

...ummm, and what's with the white background?
That is, so.. last millenium!   ;-)

[ Good content, though.   :-) ]

-- 
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology

Andrew Thompson wrote:

> > http://www.xmission.com/~goodhill/dates/deltaDates.html
> >
> > If you have any suggestions for improvements to the article or code,
> > please let me know.
>
> http://www.xmission.com/~goodhill/dates/deltadates.html
>
> (URL's with upper case are a hassle..)

Agreed that they are a hassle (and I wish /I/ had never used any), but
invalidating an existing URL is surely worse.

    -- chris

Paul Lutus wrote:
> The are any number of such special reference frames, but for everyday
> purposes, you can subtract two millisecond values in Java and get something
> useful and consistent.

One old point:

The OP and the arguments about that code were about calculating differences of 
days, not raw differences in milliseconds, second, minutes or hours

Now on to increasing millisecond sequences regardless of the whether you want 
them for subtraction of days, hours, minutes or seconds.

Thomas Marshall asked:
 >On all machine, in all locales, is the progression of java
 >milliseconds guaranteed to be linear?

In Java the VM relies on the underlying OS which relies on the hardware, 
therefore even a VM running in a special frame would consistently return 
whatever the hardware tells it. As Paul L. mentions we can ignore such odd 
special reference frame cases, but the gotcha is the hardware/OS value.

We can ignore locales and timezones, since the millisecond value is **supposed** 
to be GMT, again to the limit of the machine, so assuming the underlying 
hardware counts up then:

Answer 0: Yes, the java.util.Date millisecond value will be an ever increasing 
sequence.

You can run one of those little NTP synchronizers that keep you OS/hardware 
clock sync'ed. For more information about Network Time Protocol see:
http://tycho.usno.navy.mil/ntp.html

"Typical accuracy achieved is in the range 1 - 30 ms continuous, and is highly 
dependent on the symmetry and speed of the Internet path between client and 
server. Best results are achieved using a combination of servers which are 
closest to the client in a network sense."

So how could this effect a java millisecond values?

The value is apparently only good on your machine (not the NTP server which is 
often better) to 30 ms. For example, one NTP request might want to set your 
system clock ahead 20 ms, but then after the network is less busy, the next NTP 
check comes up with a closer value and wants to set it back maybe 15 ms.

Answer 1: NO, the sequence is not guarenteed to be increasing, because 
theoretically there could be jump backs in the millisecond value, since running 
NTP could result in resetting your clock up or down by something in the range of 
1 - 30 ms.

Since it is the resetting of your system clock downward by something akin to NTP
which is where the potential problem lies, you could have something that might 
be even more noticable on a system which
a. drifts noticably forward over a longer period (that is it's seconds are too 
short, so counts too fast)
b. runs NTP infrequently enough that this drift is noticable.

Answer 2: NO, there might be jump backs in the millisecond sequence if you have 
a system clock which drifts ahead in time and NTP service run infrequently 
enough to produce a noticable jump back.

The above are listed in increasing size of jump backs in time.

The above only apply when you create a new java.util.Date/java.util.Calendar 
based on the current time.  Many applications make up values for "midnight", "8 
AM" "last Monday", "End of the Month" using calendar calculations disconnected 
from the actual local time.

A few solutions to work around the NO scenerios are to:

1. Run NTP often enough to stay within a minute or so and be willing to work 
with time instances which are slightly off and thus
     -- pay the guy/girl whose hours you just calculated an extra 3ms, 0.3
        minutes or even 3 minutes!
     -- bill the user who connected to your system to whatever the clock said.

Because often no one is going to worry about fractions of seconds or even a 
minute or two.

I'm sure you aren't going to get far with a cell phone company with a letter:

      "To whom it may concern,  It has come to my attention that according
      to my calculations, your reconds for the remaining balance for my
      cell phone has lost 12.52 seconds ... I would appreciate being given
      a credit for your incorrect calculation" hahaha.

2. Run NTP often to keep within a few 10's of ms range, then round to an 
application appropriate value.
     -- if you are actually worried about 1/10ths and you can't suffer
     being off by a second or a 1/10th now and then (see previous solution)
     then whenever you create or us a millisecond time value from the
     system clock, you could round it to the appropriate precision.

3. Run a machine directly connected to a radio synchronized atomic time value
(see http://www.boulder.nist.gov/timefreq/stations/wwvb.htm) or able to NTP over 
a quiet network (same town or better late at night) to such a time reference to 
keep to a much closer time value than the 30ms value.

Personally, I have always taken solution #1 -- being willing to accept being off 
by a small amount of time. Many network applications are built with some 
variation of solution #2. People who _really_ care usually take solution #3.

A much bigger and more application noticable problem are scenerios which we have 
hinted at, but wanted to avoid, so haven't addressed in this thread.  I list 
some of those below.

Common Error 1: Non-synchronized clocks

A common error scenerio are clients and servers which don't run NTP, exchange 
times which are off by an application noticable amount.  I used to get this all 
the time when checking in files between a machine in (North American) 'Mountain 
Time' and machine in 'Central Time' not all of which were running NTP despite
some variation of solution #2 being part of the older/newer check used in the 
application.

Common Error 2: Forgetting TZ or DLS offsets

Another common error scenerio is to miscalculate timezone offsets so report 
inappropriate milliseconds since 1/1/1970 thus throwing an hour or more error 
into the mess.

Common Error 3: Running one machine on a timezone other than local time.

A really obvious error is a machine which is set to run its OS clock on GMT, but 
the machine is located somewhere else. For example, a user leaves the timezone 
on GMT, then sets the clock to read correct local time -- let's say New York 
time -- but since the machine is set to GMT, the VM runs on GMT, thus any 
reported millisecond time is off by the current difference between New York and 
GMT Time.

Summary

Java relies on the OS which relies on the hardware to deliver millisecond 
timestamp values.  If the OS can change the value down, for example through
running a NTP time synchronization client, the time values are not guaranteed
to be an ever increase sequence.  This is charateristic of the underlying 
machine not of a Java date (timestamp) value. In order to deal with this 
potential problem you can use a combination of frequent enough NTP resets and 
rounding of time value to an appropriate precision.  More common errors are to 
be off not by parts of minutes, but by hours due to timezone errors.


HTH,

-Paul

Chris Uppal wrote:
> Andrew Thompson wrote:

>>>http://www.xmission.com/~goodhill/dates/deltaDates.html
>>
>>http://www.xmission.com/~goodhill/dates/deltadates.html
>>
>>(URL's with upper case are a hassle..)
> 
> Agreed that they are a hassle (and I wish /I/ had never used any), but
> invalidating an existing URL is surely worse.

Now the URL is less than one day old, so I COULD change it.
But err, ah.  Can you explain?
Is it just because Domain names are case insenstive, so hand typing
the complete URL might come up with a mis-match on a name.

If I go away from mixed case URLs, how
could I directly reference a mixed case Java source file?

-Paul

p.s. I'll give it a colored background!

On Wed, 25 Aug 2004 12:03:06 -0700, P.Hill wrote:
> Answer 1: NO, the sequence is not guarenteed to be increasing,
> because theoretically there could be jump backs in the millisecond
> value, since running NTP could result in resetting your clock up or
> down by something in the range of 1 - 30 ms.

> Answer 2: NO, there might be jump backs in the millisecond sequence
> if you have a system clock which drifts ahead in time and NTP
> service run infrequently enough to produce a noticable jump back.

NTP never sets the clock backwards. Changes in that direction are
acheived by updating the system clock more slowly, so that essentially
time catches up with your machine.

From rfc1305:
  "The effect is to slew the clock to a new value at a small, constant
  rate, rather than incorporate the adjustment all at once, which
  could cause the clock to be set backward."

> Because often no one is going to worry about fractions of seconds or
> even a minute or two.

In any system with NFS mounted filesystems, even a few seconds of
discrepency between hosts can cause irritating problems. For example,
"make" won't rebuild a project if the target already exists with a
newer timestamp than files it depends on, which can easily occur if
files are updated from different systems with unsynchronized clocks.
The NTP faq gives further examples; this is one I've run into a few
times.

/gordon

-- 
[  do not email me copies of your followups  ]
g o r d o n + n e w s @  b a l d e r 1 3 . s e

Michael Borgwardt <brazil@brazils-animeland.de> coughed up the
following:
> Thomas G. Marshall wrote:
>> Are there any jump discontinuities or ramping up or ramping down to
>> accommodate changes in leap seconds, etc., for the odd locale?
>
> This really has nothing to do with Java and everything to do with how
> the underlying operating system implements its clock in regard to
> leap seconds, daylight savings switches, etc.

Yep, ok.


> Usually, this will result in sudden leaps of clock time, e.g. when
> the clock is adjusted by a Network Time Protocol client. Of course,
> the same thing happens when a user adjusts the time manually.

The question is whether or not the time leap occurs at the millisecond level
as well.

I can imagine a system where the milliseconds are uniformly and ever
increasing, one after the other, and the time leaps are done by calculation.

I can also imagine a system where the time leaps are back channeled to the
millisecond "generator".


>
> Another notable fact is that common OS's clocks are coarser than
> the millisecond precision assumed by java, so the time will appear
> to progress in little jumps of about 10 milliseconds

-- 
Forgetthesong,I'dratherhavethefrontallobotomy...

P.Hill <goodhill.REMOVE@xmissionREMOVE.com> coughed up the following:
> Paul Lutus wrote:
>> The are any number of such special reference frames, but for everyday
>> purposes, you can subtract two millisecond values in Java and get
>> something useful and consistent.
>
> One old point:
>
> The OP and the arguments about that code were about calculating
> differences of days, not raw differences in milliseconds, second,
> minutes or hours
>
> Now on to increasing millisecond sequences regardless of the whether
> you want them for subtraction of days, hours, minutes or seconds.
>
> Thomas Marshall asked:
>  >On all machine, in all locales, is the progression of java
>  >milliseconds guaranteed to be linear?
>
> In Java the VM relies on the underlying OS which relies on the
> hardware, therefore even a VM running in a special frame would
> consistently return whatever the hardware tells it. As Paul L.
> mentions we can ignore such odd special reference frame cases, but
> the gotcha is the hardware/OS value.
>
> We can ignore locales and timezones, since the millisecond value is
> **supposed** to be GMT, again to the limit of the machine, so
> assuming the underlying hardware counts up then:
>
> Answer 0: Yes, the java.util.Date millisecond value will be an ever
> increasing sequence.

Ah.


> You can run one of those little NTP synchronizers that keep you
> OS/hardware clock sync'ed. For more information about Network Time
> Protocol see: http://tycho.usno.navy.mil/ntp.html
>
> "Typical accuracy achieved is in the range 1 - 30 ms continuous, and
> is highly dependent on the symmetry and speed of the Internet path
> between client and server. Best results are achieved using a
> combination of servers which are closest to the client in a network
> sense."
>
> So how could this effect a java millisecond values?
>
> The value is apparently only good on your machine (not the NTP server
> which is often better) to 30 ms. For example, one NTP request might
> want to set your system clock ahead 20 ms, but then after the network
> is less busy, the next NTP check comes up with a closer value and
> wants to set it back maybe 15 ms.
>
> Answer 1: NO, the sequence is not guarenteed to be increasing, because
> theoretically there could be jump backs in the millisecond value,
> since running NTP could result in resetting your clock up or down by
> something in the range of 1 - 30 ms.

I see why there are two answers.


> Since it is the resetting of your system clock downward by something
> akin to NTP which is where the potential problem lies, you could have
> something that might be even more noticable on a system which
> a. drifts noticably forward over a longer period (that is it's
> seconds are too short, so counts too fast)
> b. runs NTP infrequently enough that this drift is noticable.
>
> Answer 2: NO, there might be jump backs in the millisecond sequence
> if you have a system clock which drifts ahead in time and NTP service
> run infrequently enough to produce a noticable jump back.

So, without NTP (and other similar outside events) the ms clock is not only
monotonically increasing, it is perfectly linear.

With NTP, the ms clock is possibly non-monotonic, (and :. non-linear.)


>
> The above are listed in increasing size of jump backs in time.
>
> The above only apply when you create a new
> java.util.Date/java.util.Calendar based on the current time.  Many
> applications make up values for "midnight", "8 AM" "last Monday",
> "End of the Month" using calendar calculations disconnected from the
> actual local time.
>
> A few solutions to work around the NO scenerios are to:
>
> 1. Run NTP often enough to stay within a minute or so and be willing
> to work with time instances which are slightly off and thus
>      -- pay the guy/girl whose hours you just calculated an extra
>         3ms, 0.3 minutes or even 3 minutes!
>      -- bill the user who connected to your system to whatever the
> clock said.
>
> Because often no one is going to worry about fractions of seconds or
> even a minute or two.
>
> I'm sure you aren't going to get far with a cell phone company with a
> letter:
>
>       "To whom it may concern,  It has come to my attention that
>       according to my calculations, your reconds for the remaining
>       balance for my cell phone has lost 12.52 seconds ... I would
>       appreciate being given a credit for your incorrect calculation"
> hahaha.
>
> 2. Run NTP often to keep within a few 10's of ms range, then round to
> an application appropriate value.
>      -- if you are actually worried about 1/10ths and you can't suffer
>      being off by a second or a 1/10th now and then (see previous
>      solution) then whenever you create or us a millisecond time
>      value from the system clock, you could round it to the
> appropriate precision.
>
> 3. Run a machine directly connected to a radio synchronized atomic
> time value (see
> http://www.boulder.nist.gov/timefreq/stations/wwvb.htm) or able to
> NTP over a quiet network (same town or better late at night) to such
> a time reference to keep to a much closer time value than the 30ms
> value.
>
> Personally, I have always taken solution #1 -- being willing to
> accept being off by a small amount of time. Many network applications
> are built with some variation of solution #2. People who _really_
> care usually take solution #3.
>
> A much bigger and more application noticable problem are scenerios
> which we have hinted at, but wanted to avoid, so haven't addressed in
> this thread.  I list some of those below.
>
> Common Error 1: Non-synchronized clocks
>
> A common error scenerio are clients and servers which don't run NTP,
> exchange times which are off by an application noticable amount.  I
> used to get this all the time when checking in files between a
> machine in (North American) 'Mountain Time' and machine in 'Central
> Time' not all of which were running NTP despite some variation of
> solution #2 being part of the older/newer check used in the
> application.
>
> Common Error 2: Forgetting TZ or DLS offsets
>
> Another common error scenerio is to miscalculate timezone offsets so
> report inappropriate milliseconds since 1/1/1970 thus throwing an
> hour or more error into the mess.
>
> Common Error 3: Running one machine on a timezone other than local
> time.
>
> A really obvious error is a machine which is set to run its OS clock
> on GMT, but the machine is located somewhere else. For example, a
> user leaves the timezone on GMT, then sets the clock to read correct
> local time -- let's say New York time -- but since the machine is set
> to GMT, the VM runs on GMT, thus any reported millisecond time is off
> by the current difference between New York and GMT Time.
>
> Summary
>
> Java relies on the OS which relies on the hardware to deliver
> millisecond timestamp values.  If the OS can change the value down,
> for example through running a NTP time synchronization client, the
> time values are not guaranteed to be an ever increase sequence.  This
> is charateristic of the underlying machine not of a Java date
> (timestamp) value. In order to deal with this potential problem you
> can use a combination of frequent enough NTP resets and rounding of
> time value to an appropriate precision.  More common errors are to be
> off not by parts of minutes, but by hours due to timezone errors.
>
>
> HTH,
>
> -Paul

-- 
Forgetthesong,I'dratherhavethefrontallobotomy...

Thomas G. Marshall
<tgm2tothe10thpower@replacetextwithnumber.hotmail.com> coughed up the
following:
> P.Hill <goodhill.REMOVE@xmissionREMOVE.com> coughed up the following:
>> Paul Lutus wrote:
>>> The are any number of such special reference frames, but for
>>> everyday purposes, you can subtract two millisecond values in Java
>>> and get something useful and consistent.
>>
>> One old point:
>>
>> The OP and the arguments about that code were about calculating
>> differences of days, not raw differences in milliseconds, second,
>> minutes or hours
>>
>> Now on to increasing millisecond sequences regardless of the whether
>> you want them for subtraction of days, hours, minutes or seconds.
>>
>> Thomas Marshall asked:
>>  >On all machine, in all locales, is the progression of java
>>  >milliseconds guaranteed to be linear?
>>
>> In Java the VM relies on the underlying OS which relies on the
>> hardware, therefore even a VM running in a special frame would
>> consistently return whatever the hardware tells it. As Paul L.
>> mentions we can ignore such odd special reference frame cases, but
>> the gotcha is the hardware/OS value.
>>
>> We can ignore locales and timezones, since the millisecond value is
>> **supposed** to be GMT, again to the limit of the machine, so
>> assuming the underlying hardware counts up then:
>>
>> Answer 0: Yes, the java.util.Date millisecond value will be an ever
>> increasing sequence.
>
> Ah.
>
>
>> You can run one of those little NTP synchronizers that keep you
>> OS/hardware clock sync'ed. For more information about Network Time
>> Protocol see: http://tycho.usno.navy.mil/ntp.html
>>
>> "Typical accuracy achieved is in the range 1 - 30 ms continuous, and
>> is highly dependent on the symmetry and speed of the Internet path
>> between client and server. Best results are achieved using a
>> combination of servers which are closest to the client in a network
>> sense."
>>
>> So how could this effect a java millisecond values?
>>
>> The value is apparently only good on your machine (not the NTP server
>> which is often better) to 30 ms. For example, one NTP request might
>> want to set your system clock ahead 20 ms, but then after the network
>> is less busy, the next NTP check comes up with a closer value and
>> wants to set it back maybe 15 ms.
>>
>> Answer 1: NO, the sequence is not guarenteed to be increasing,
>> because theoretically there could be jump backs in the millisecond
>> value,
>> since running NTP could result in resetting your clock up or down by
>> something in the range of 1 - 30 ms.
>
> I see why there are two answers.
>
>
>> Since it is the resetting of your system clock downward by something
>> akin to NTP which is where the potential problem lies, you could have
>> something that might be even more noticable on a system which
>> a. drifts noticably forward over a longer period (that is it's
>> seconds are too short, so counts too fast)
>> b. runs NTP infrequently enough that this drift is noticable.
>>
>> Answer 2: NO, there might be jump backs in the millisecond sequence
>> if you have a system clock which drifts ahead in time and NTP service
>> run infrequently enough to produce a noticable jump back.
>
> So, without NTP (and other similar outside events) the ms clock is
> not only monotonically increasing, it is perfectly linear.
>
> With NTP, the ms clock is possibly non-monotonic, (and :. non-linear.)

as per Gordon Beaton's point, the ms clock is /always/ monotonically
increasing, and often non-linear.

....[rip]...


-- 
Forgetthesong,I'dratherhavethefrontallobotomy...

Gordon Beaton wrote:
> From rfc1305:
>   "The effect is to slew the clock to a new value at a small, constant
>   rate, rather than incorporate the adjustment all at once, which
>   could cause the clock to be set backward."

Cool!  I didn't know that bit.  Thanks for the input and the correction.
Is this possible on an Intel chip?  Can you tell it to 'skip one'
or 'double up' a bunch of clock cycles, so the system
clock never sees a jump back of any size even a series
of very small ones?

> In any system with NFS mounted filesystems, even a few seconds of
> discrepency between hosts can cause irritating problems. 
[...]
> The NTP faq gives further examples; this is one I've run into a few
> times.

I've run into that one myself many times, even to a server that I don't have
control over, when I am running NTP on a simple Windoze box.

-Paul

On Wed, 25 Aug 2004 12:38:46 -0700, P.Hill wrote:

> If I go away from mixed case URLs, 

This is a good thing, where practical..

> how could I directly reference a mixed case Java source file?

...I would stick with exact case in that situation
(or perhaps more accurately, I *do* stick with that)

> p.s. I'll give it a colored background!

Cool.. So many colors to choose from!

-- 
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology

P.Hill wrote:

> > > (URL's with upper case are a hassle..)
> >
> > Agreed that they are a hassle (and I wish /I/ had never used any), but
> > invalidating an existing URL is surely worse.
>
> Now the URL is less than one day old, so I COULD change it.

Happy Birthday !


> But err, ah.  Can you explain?
> Is it just because Domain names are case insenstive, so hand typing
> the complete URL might come up with a mis-match on a name.

Yes.  URLs are case-sensitive, but people are irritatingly inconsistent in
this.  At least, it seems to be unsafe to expect people (even programmers) to
get the case right in "normal" mixed-case URLs.


> If I go away from mixed case URLs, how
> could I directly reference a mixed case Java source file?

Like, Andrew, I think I'd stick with CamelCase for these files -- after all if
a Java programmer doesn't know the rules then (let's be frank) who cares if
they get it wrong ?  (And if they're /not/ Java programmers then why are they
reading your .java files ?)

    -- chris

P.Hill wrote:

> Gordon Beaton wrote:
> 
>> From rfc1305:
>>   "The effect is to slew the clock to a new value at a small, constant
>>   rate, rather than incorporate the adjustment all at once, which
>>   could cause the clock to be set backward."
> 
> 
> Cool!  I didn't know that bit.  Thanks for the input and the correction.

Hmm, I just found the quote you mentioned.  It is in the section
7.1.2 Unix Clock Model
There does not seem to be any other mention of slewing in
the entire document outside of this specialized section.

Information on making sure your Windows system is running SNTP is availble from 
no less than NIST Boulder (the folks who keep Atomic Time in the Western US)
at: http://www.boulder.nist.gov/timefreq/service/pdf/win2000xp.pdf
See section 5.

I still don't see any guarantees anywhere that time will never jump back,
but I'm encouraged by the quote Gordon mentioned.

thanks,
-Paul

P.Hill wrote:

> Erwin Moller wrote:
>> Hi group,
>> 
>> (Sorry for complaining)
>> Is it just me or do dates, milliseconds, GregorianCalendar completely
>> confusing?
> 
> Apparently so, judging from the arguments that can erupt over such
> calculations. In the interest of trying to avoid having to explain this
> yet again to another person who thinks they know the answer and trying to
> point out that ( day1Milliseconds - day2Milliseconds ) /
> MILLISECONDS_PER_DAY is NOT the correct answer for many values of day1 and
> day2 I suggest you, the reader interested in this problem, see:
> http://www.xmission.com/~goodhill/dates/deltaDates.html
> 
> If you have any suggestions for improvements to the article or code,
> please let me know.
> 
> -Paul Hill

Great summary Paul!

Thanks from the OP for making a website on this issue. :-)
I hope futher newbies on the matter, like me, will find it too.

Regards,
Erwin Moller