This discussion is archived
10 Replies Latest reply: Mar 9, 2011 6:43 AM by YoungWinston RSS

Calendar behaving in awkward way.

804103 Newbie
Currently Being Moderated
Having an issue with Calendar (it is showing incorrect day).
Pre-Condition : My computer's Time-Zone is set to Asia(Chennia/New Delhi/Mumbai/Calcutta).Program run time 08th march,2011 at 08:54 PM.
TimeZone tz = TimeZone.getTimeZone("America/New_York");
Calendar start = Calendar.getInstance(tz,new Locale("English"));
System.out.println(start.getTime());
start.setTime(new Date());
System.out.println(start.getTime());
start.set(2011,03,11);
System.out.println(start.getTime());
Output:
Tue Mar 08 20:54:02 IST 2011
Tue Mar 08 20:54:05 IST 2011
Mon Apr 11 19:54:05 IST 2011

Query : :
The third date shown in output is incorrect.It should be Fri Mar 11 20:54:55 IST 2011"

Can anyone assist on the same.
Thanks in advance.
  • 1. Re: Calendar behaving in awkward way.
    gimbal2 Guru
    Currently Being Moderated
    Calendar trap: month is zero based. So jan = 0, feb = 1, mar = 2.
  • 2. Re: Calendar behaving in awkward way.
    796440 Guru
    Currently Being Moderated
    gimbal2 wrote:
    Calendar trap: month is zero based. So jan = 0, feb = 1, mar = 2.
    Which is why you should use Calendar.JANUARY, not 1.
  • 3. Re: Calendar behaving in awkward way.
    YoungWinston Expert
    Currently Being Moderated
    jverd wrote:
    gimbal2 wrote:
    Calendar trap: month is zero based. So jan = 0, feb = 1, mar = 2.
    Which is why you should use Calendar.JANUARY, not 1.
    Have to admit, that was a silly decision on the part of the Java developers. A moment's laziness possibly...

    Winston
  • 4. Re: Calendar behaving in awkward way.
    796440 Guru
    Currently Being Moderated
    YoungWinston wrote:
    jverd wrote:
    gimbal2 wrote:
    Calendar trap: month is zero based. So jan = 0, feb = 1, mar = 2.
    Which is why you should use Calendar.JANUARY, not 1.
    Have to admit, that was a silly decision on the part of the Java developers. A moment's laziness possibly...

    Winston
    Not sure I agree.

    We don't use 1 for Sunday or Monday. And it might be that some of the internal math is clearer if it doesn't always have to account for an offset of 1. Zero-based calculations are the norm and are generally simpler in many programming contexts. I don't care about the 1 value of January. I want to refer to it by a constant.
  • 5. Re: Calendar behaving in awkward way.
    YoungWinston Expert
    Currently Being Moderated
    jverd wrote:
    We don't use 1 for Sunday or Monday. And it might be that some of the internal math is clearer if it doesn't always have to account for an offset of 1. Zero-based calculations are the norm and are generally simpler in many programming contexts. I don't care about the 1 value of January. I want to refer to it by a constant.
    I totally agree with your last point and your advice; my only question is Java's use of 0 for January as a client-visible choice. Every place we (Gregorian Western world "we") read and write dates, January is 1 - except when you're using a Java Calendar constructor. Surely, it would have been an easy thing to subtract 1 internally?

    That said, I wish enums had been around when that class was written.

    Winston
  • 6. Re: Calendar behaving in awkward way.
    796440 Guru
    Currently Being Moderated
    YoungWinston wrote:
    jverd wrote:
    We don't use 1 for Sunday or Monday. And it might be that some of the internal math is clearer if it doesn't always have to account for an offset of 1. Zero-based calculations are the norm and are generally simpler in many programming contexts. I don't care about the 1 value of January. I want to refer to it by a constant.
    I totally agree with your last point and your advice; my only question is Java's use of 0 for January as a client-visible choice. Every place we (Gregorian Western world "we") read and write dates, January is 1 - except when you're using a Java Calendar constructor.
    new GergorianCalendar(2011, Calendar.MARCH, 7);
    I wonder if the (int, int, int) constructor would even have existed--indeed, if MARCH, TUESDAY, etc. would even have been ints--if enums had been part of the language from the start.
    Surely, it would have been an easy thing to subtract 1 internally?
    I can see where it might be error-prone to make the adjustment wherever it's needed, but that's just speculation on my part.
    That said, I wish enums had been around when that class was written.
    Ah, you read my mind, good sir.
  • 7. Re: Calendar behaving in awkward way.
    YoungWinston Expert
    Currently Being Moderated
    jverd wrote:
    I can see where it might be error-prone to make the adjustment wherever it's needed, but that's just speculation on my part.
    Hmmm, constructors that take a month as an int and related 'set' methods? Hey, it's too late now, so I'm just spitting in the wind, but it does strike me as a fairly basic mistake.
    new GergorianCalendar(2011, Calendar.MARCH, 7)
    Yup, the way it should be done, we both agree; but what about the poor sod who writes
    new GergorianCalendar(2011, 3, 7)
    and spends a week working out why his tax calculation program isn't working (April 6th just happens to be 'tax day' in the UK)?

    Winston
  • 8. Re: Calendar behaving in awkward way.
    796440 Guru
    Currently Being Moderated
    YoungWinston wrote:
    Yup, the way it should be done, we both agree; but what about the poor sod who writes
    new GergorianCalendar(2011, 3, 7)
    and spends a week working out why his tax calculation program isn't working (April 6th just happens to be 'tax day' in the UK)?
    Sure, it's a natural assumption to make, but when it doesn't work, you start checking your assumptions, and call me a dick, but I don't have much pity for the guy who doesn't read the docs closely enough or apply enough reasoning to work out what's wrong there pretty quickly.

    The mapping are counter-intuitive, no doubt, and perhaps should have been done differently, but they're not that mysterious, and the docs to state explicitly that months are zero-based. If someone can't be bothered to read them, even after he sees confusing behavior, I wouldn't blame the tool.
  • 9. Re: A moment's laziness
    803691 Newbie
    Currently Being Moderated
    A moment's laziness possibly...
    Old Winston would remember good old C...

    http://www.gnu.org/s/libc/manual/html_node/Broken_002ddown-Time.html#Broken_002ddown-Time

    — Data Type: struct tm

    This is the data type used to represent a broken-down time. The structure contains at least the following members, which can appear in any order.

    int tm_sec
    This is the number of full seconds since the top of the minute (normally in the range 0 through 59, but the actual upper limit is 60, to allow for leap seconds if leap second support is available).
    int tm_min
    This is the number of full minutes since the top of the hour (in the range 0 through 59).
    int tm_hour
    This is the number of full hours past midnight (in the range 0 through 23).
    int tm_mday
    This is the ordinal day of the month (in the range 1 through 31). Watch out for this one! As the only ordinal number in the structure, it is inconsistent with the rest of the structure.
    int tm_mon
    This is the number of full calendar months since the beginning of the year (in the range 0 through 11). Watch out for this one! People usually use ordinal numbers for month-of-year (where January = 1).
  • 10. Re: A moment's laziness
    YoungWinston Expert
    Currently Being Moderated
    BIJ wrote:
    Old Winston would remember good old C...
    — Data Type: struct tm
    Oh God, struct tm, strftime...I'm having flashbacks....

    Winston

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points