it's a bug of calendar?
Hello i have a simple code with calculate te day of week
it's a output
Month0 is 2
Month1 is 5
Month2 is 5
Month3 is 1
Month4 is 3
Month5 is 6
Month6 is 1
Month7 is 4
Month8 is 7
Month9 is 2
Month10 is 5
Month11 is 7
i 've see the very calendar but it's an error?
for (int i=0; i<12; i++)
{
Locale locale =new Locale("it","IT");
GregorianCalendar xmas =new GregorianCalendar(locale);
xmas.set(Calendar.YEAR, 2007);
xmas.set(Calendar.DAY_OF_MONTH, 1);
xmas.set(Calendar.MONTH, i);
System.out.println("Month"+i +" is "+xmas.get(Calendar.DAY_OF_WEEK));
}
[989 byte] By [
nturria] at [2007-11-27 10:31:21]
You're asking it for the DAY_OF_WEEK, not MONTH
Some bug
Actually, it looks correct.
You should not rely on integral values of fields, they might be confusing. For example, the days in week values are:
1 - SUNDAY
2 - MONDAY
...
7 - SATURDAY
I have need to calculate the first day of every month ,
i think that this is a bug .
> I have need to calculate the first day of every
> month ,
>i think that this is a bug .
Fair enough. Raise a bug report then
> I have need to calculate the first day of every
> month ,
>i think that this is a bug .
Could you elaborate? what is your expected output ?
Your program tells you, for every month's first day, which day of the week it is.Your current outputHow it should be interpreted
--
Month0 is 2 JANUARY - MONDAY
Month1 is 5 FEBRUARY - THURSDAY
Month2 is 5 MARCH - THURSDAY
Month3 is 1 APRIL - SUNDAY
Month4 is 3 MAY - TUESDAY
Month5 is 6 JUNE - FRIDAY
Month6 is 1 JULY - SUNDAY
Month7 is 4 AUGUST - WEDNESDAY
Month8 is 7 SEPTEMBER - SATURDAY
Month9 is 2 OCTOBER - MONDAY
Month10 is 5NOVEMBER - THURSDAY
Month11 is 7DECEMBER - SATURDAY
> I have need to calculate the first day of every
> month ,
>i think that this is a bug .
The bug is in your code. You have been told of two problems which you seem to want to ignore.
Go ahead, raise a bug report and make a fool of yourself.
> 1= sunday?it's ok
It's irrelevant
The first day of every month is the 1st. I'm pretty certain that each month in the Gregorian calendar starts at day #1.
You may have meant something else, of course, but if you can't even describe your goal precisely then it's unlikely that you can describe errors in your program's output, and it's even less likely that you'd be correct when you blame the API
java.util.Calendar has been available for ten years. If there was a bug as trivial as this one, it's unlikely that it would have gone unnoticed.
It's typical of noobs to blame their errors or lack of understanding on "bugs".
%
> 1= sunday?it's ok
As said before, you shouldn't rely on numeral values of Calendar's fields. I mentionned them just so that you understand that you were mistakenly interpreting your program's output.
A somewhat cleaner version of your code could be :Locale locale = new Locale("it", "IT");
SimpleDateFormat dateFormat = new SimpleDateFormat("'Month 'MMMM' is 'EEEE", locale);
Calendar calendar = Calendar.getInstance(locale);
calendar.set(Calendar.YEAR, 2007);
calendar.set(Calendar.DAY_OF_MONTH, 1);
for (int month = Calendar.JANUARY; month <= Calendar.DECEMBER; month ++) {
calendar.set(Calendar.MONTH, month);
System.out.println(dateFormat.format(calendar.getTime()));
}
http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html
Tim - an interesting approach to learning month/day names in other languages...
> for (int month = Calendar.JANUARY; month <=
> Calendar.DECEMBER; month ++) {
Tim,
This implies an ordering for January, February, March etc that is not guaranteed by the Javadoc. The only safe way to do this is to build up an array containing the integer values January, Februaray, March etc and then iterate over the array.
Using your example as basis,
Locale locale = new Locale("it", "IT");
SimpleDateFormat dateFormat = new SimpleDateFormat("'Month 'MMMM' is 'EEEE", locale);
final int[] months =
{
Calendar.JANUARY,
Calendar.FEBRUARY,
Calendar.MARCH,
Calendar.APRIL,
Calendar.MAY,
Calendar.JUNE,
Calendar.JULY,
Calendar.AUGUST,
Calendar.SEPTEMBER,
Calendar.OCTOBER,
Calendar.NOVEMBER,
Calendar.DECEMBER,
};
Calendar calendar = Calendar.getInstance(locale);
calendar.set(Calendar.YEAR, 2007);
calendar.set(Calendar.DAY_OF_MONTH, 1);
for (int month : months)
{
calendar.set(Calendar.MONTH, month);
System.out.println(dateFormat.format(calendar.getTime()));
}
Sabre
Message was edited by:
sabre150
If only they'd considered enums 10 years ago.
> If only they'd considered enums 10 years ago.
Well, that's an RFE thought. Ask to have a public enum built into the specific Calendar classes (i.e. GergorianCalendar) for the months and weekdays. Or is there one and I'm only making a fool of myself?
;-)
> > If only they'd considered enums 10 years ago.
>
> Well, that's an RFE thought. Ask to have a public
> enum built into the specific Calendar classes (i.e.
> GergorianCalendar) for the months and weekdays. Or
> is there one and I'm only making a fool of myself?
>
I think the problem is the amount of legacy code it would break. Too much code has been written that assumes specific int values for January, February etc.
Even the code I posted assumes that the values are ints (since the Javadoc does say they are).
Message was edited by:
sabre150
why? There's already the constants indicating everything...
Just use Calendar.MONDAY instead of hardcoding the numerical value for example.
> why? There's already the constants indicating
> everything...
But in my view these 'int' constants would have been better as instances of (say) a Month class using the enum pattern.
> Just use Calendar.MONDAY instead of hardcoding the
> numerical value for example.
I think this has been covered.
> why? There's already the constants indicating
> everything...
But you can't iterate over constants. Further, you could make thos months and days objects, with a way to ask them for their localized names...
aCalendar.getMonth.getName(aLocale) is much nicer than filling a date formatter first.
You could also make them have indices which would match the Calendar constants, so you could instead of replacing GregorianCalendar have an ImprovedGregorianCalendar (or KervorkianCalendar) that features both. getEnumeratedMonth() or something.
Something like that, I currently don't feel much like thinking.
> This implies an ordering for January, February, March etc that is not
> guaranteed by the Javadoc.
Yep, I agree.
> The only safe way to do this is to build up an array containing the
> integer values January, Februaray, March etc and then iterate over the
> array.
However, the only safe way would be to use the roll method, which provides the cleanest iterator-like behaviour IMHO :calendar.set(Calendar.MONTH, Calendar.JANUARY);
do {
System.out.println(dateFormat.format(calendar.getTime()));
calendar.roll(Calendar.MONTH, true);
} while (calendar.get(Calendar.MONTH) != Calendar.JANUARY);
In fact, how about an implementation of a lunisolar calendar, in which a year is divided in either 12 or 13 months, depending on the year.
With the roll approach, we don't have to know the range of the field in advance, so it can be applied to other fields (e.g. days of month) the same way: calendar.set(Calendar.DAY_OF_MONTH, 1);
calendar.set(Calendar.MONTH, Calendar.FEBRUARY);
do {
System.out.println(dateFormat.format(calendar.getTime()));
calendar.roll(Calendar.DAY_OF_MONTH, true);
} while (calendar.get(Calendar.DAY_OF_MONTH) != 1);
Well, I didn't really thought about all the possible enhancements of the Calendar. But it's true that the current field-based approach might miss a bit of OO taste.
Tim - Can you hear February crying: I am not a number !
