10 Replies Latest reply: Mar 9, 2011 8:43 AM by YoungWinston RSS

    Calendar behaving in awkward way.

    804103
      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
          Calendar trap: month is zero based. So jan = 0, feb = 1, mar = 2.
          • 2. Re: Calendar behaving in awkward way.
            796440
            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
              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
                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
                  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
                    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
                      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
                        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
                          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
                            BIJ wrote:
                            Old Winston would remember good old C...
                            — Data Type: struct tm
                            Oh God, struct tm, strftime...I'm having flashbacks....

                            Winston