java.util.Calendar question

[laredotornado]

Hi,

I'm using Java 1.6 on Mac 10.6.3. I'm trying to get the closest
Sunday before today, unless today is Sunday in which case I don't want
to change my calendar object. Here is what I have ...

cal.set(Calendar.DAY_OF_MONTH, 1);
while (cal.get(Calendar.DAY_OF_WEEK) != Calendar.SUNDAY) {
cal.add(Calendar.DAY_OF_YEAR, -1);
out.println("\t<!-- iterating through cal:" +
cal.getTime().toString() + "-->");
}

However, this loop is consistently returning a calendar instance that
is Saturday. Any ideas of something obvious that I'm missing here?

Thanks for your help, - Dave

 

[markspace]

However, this loop is consistently returning a calendar instance that
is Saturday. Any ideas of something obvious that I'm missing here?

This worked for me:

<code>
public class CalendarTest {
public static void main( String[] args )
{
Calendar c = Calendar.getInstance();
System.err.println( Calendar.SUNDAY );
System.err.println( c.get( Calendar.DAY_OF_WEEK ) );
while( c.get( Calendar.DAY_OF_WEEK ) != Calendar.SUNDAY ) {
c.roll( Calendar.DAY_OF_WEEK, -1 );
System.err.println( c.get( Calendar.DAY_OF_WEEK ) );
System.err.println( c.getTime() );
}

}
}
</code>
<output>
run:
1
4
3
Tue May 04 13:10:08 PDT 2010
2
Mon May 03 13:10:08 PDT 2010
1
Sun May 02 13:10:08 PDT 2010
BUILD SUCCESSFUL (total time: 1 second)
</output>

 

[Lew]

This worked for me:

<code>
public class CalendarTest {
public static void main( String[] args )
{
Calendar c = Calendar.getInstance();
System.err.println( Calendar.SUNDAY );
System.err.println( c.get( Calendar.DAY_OF_WEEK ) );
while( c.get( Calendar.DAY_OF_WEEK ) != Calendar.SUNDAY ) {
c.roll( Calendar.DAY_OF_WEEK, -1 );
System.err.println( c.get( Calendar.DAY_OF_WEEK ) );
System.err.println( c.getTime() );
}
}
}
</code>
<output>
run:
1
4
3
Tue May 04 13:10:08 PDT 2010
2
Mon May 03 13:10:08 PDT 2010
1
Sun May 02 13:10:08 PDT 2010
BUILD SUCCESSFUL (total time: 1 second)
</output>

The problem there is the suspect definition of 'roll()':
"Adds the specified (signed) amount to the specified calendar field without
changing larger fields"

as opposed to 'add()', which reconciles the other fields.

 

[Lew]

I'm using Java 1.6 on Mac 10.6.3. I'm trying to get the closest
Sunday before today, unless today is Sunday in which case I don't want
to change my calendar object. Here is what I have ...

cal.set(Calendar.DAY_OF_MONTH, 1);

Are you quite certain you indented your code far enough? It's still readable,
so I think you didn't.

while (cal.get(Calendar.DAY_OF_WEEK) != Calendar.SUNDAY) {
cal.add(Calendar.DAY_OF_YEAR, -1);
out.println("\t<!-- iterating through cal:" +
cal.getTime().toString() + "-->");
}

<http://sscce.org/>
<http://sscce.org/>
<http://sscce.org/>
<http://sscce.org/>
<http://sscce.org/>
<http://sscce.org/>
<http://sscce.org/>

Gosh darn it!

However, this loop is consistently returning a calendar instance that
is Saturday. Any ideas of something obvious that I'm missing here?

The problem, of course, is in the code you refused to show us because you
didn't provide an SSCCE.

Are you /trying/ to prevent us from helping you?

<sscce>
package eegee;

import java.util.Calendar;
import org.junit.Test;
import static org.junit.Assert.assertEquals;

public class Calendroll
{
@test
public void test()
{
Calendar cal = Calendar.getInstance();
cal.set( Calendar.DAY_OF_MONTH, 1 );

findSunday( cal );
assertEquals( Calendar.SUNDAY, cal.get( Calendar.DAY_OF_WEEK ));

cal.set( Calendar.YEAR, 1999 );
cal.set( Calendar.MONTH, Calendar.DECEMBER );
cal.set( Calendar.DAY_OF_MONTH, 31 );

findSunday( cal );
assertEquals( Calendar.SUNDAY, cal.get( Calendar.DAY_OF_WEEK ));
}

private void findSunday( Calendar cal )
{
while (cal.get(Calendar.DAY_OF_WEEK) != Calendar.SUNDAY)
{
cal.add(Calendar.DAY_OF_YEAR, -1);
}
}
}
</sscce>

Works for me (running in JUnit framework).

 

[markspace]

The problem there is the suspect definition of 'roll()':
"Adds the specified (signed) amount to the specified calendar field
without changing larger fields"

as opposed to 'add()', which reconciles the other fields.

True, and I noticed that well after I posted. Still, at least my
example compiles, unlike the OP's.

 

[Roedy Green]

Hi,

I'm using Java 1.6 on Mac 10.6.3. I'm trying to get the closest
Sunday before today, unless today is Sunday in which case I don't want
to change my calendar object. Here is what I have ...

Calendar is not really designed for pure date calculations. It is more
for timestamps.

You will find that problem trivial to solve with BigDate. See
http://mindprod.com/products.html#COMMON11

 

[Stanimir Stamenkov]

Wed, 5 May 2010 12:33:15 -0700 (PDT), /laredotornado/:

I'm trying to get the closest Sunday before today, unless today is
Sunday in which case I don't want to change my calendar object. Here
is what I have ...
cal.set(Calendar.DAY_OF_MONTH, 1);
while (cal.get(Calendar.DAY_OF_WEEK) != Calendar.SUNDAY) {
cal.add(Calendar.DAY_OF_YEAR, -1);
out.println("\t<!-- iterating through cal:"
+ cal.getTime().toString() + "-->");
}
However, this loop is consistently returning a calendar instance that
is Saturday. Any ideas of something obvious that I'm missing here?

May be something simpler like:

Calendar cal = Calendar.getInstance();
System.out.println(cal.getTime());

cal.add(Calendar.DATE, -7);
cal.set(Calendar.DAY_OF_WEEK, Calendar.SUNDAY);
cal.add(Calendar.DATE, 7);
System.out.println(cal.getTime());

Next, If you perform the same operation on the result which is already
Sunday, you will notice it doesn't change:

cal.add(Calendar.DATE, -7);
cal.set(Calendar.DAY_OF_WEEK, Calendar.SUNDAY);
cal.add(Calendar.DATE, 7);
System.out.println(cal.getTime());

 

[Lew]

Calendar is not really designed for pure date calculations. It is more
for timestamps.

Calendar is totally and pointedly designed for pure date calculations. How
could you mislead people like that?

Futhermore, running the OP's code here (what little they posted) does not
reproduce the OP's error.

 

[Arne Vajhøj]

Calendar is totally and pointedly designed for pure date calculations.
How could you mislead people like that?

I would say designed for date & time calculations and working fine for
data calculations.

Working fine as in solving the problem. There are some people that
think the API could be improved.

Regarding Roedy, then I assume that his post was primarily just to post
a link to some of his own stuff.

Arne