You might wonder why this is the case. The origins lie with the POSIX
standard functions |ctime|, |gmtime| and |localtime|, which accept or
return a |time_t| structure with the following fields (from man 3 ctime
|int tm_mday; /* day of month (1 - 31) */
int tm_mon; /* month of year (0 - 11) */
int tm_year; /* year - 1900 */
This API was copied pretty much exactly into the Java Date class in Java
1.0, and from there mostly intact into the Calendar class in Java 1.1.
Sun fixed the most glaring problem when they introduced Calendar – the
fact that the year 2001 in the Gregorian calendar was represented by the
value 101 in their Date class. But I'm not sure why they didn't change
the day and month values to at least both be consistent in their
indexing, either from zero or one. This inconsistency and related
confusion still exists in Java (and C) to this day."
On 09/08/12 12:46, Jürgen Gluch wrote:
> I noticed today (2012 Aug 09) that the macro:
> getDateAndTime(year, month, dayOfWeek, dayOfMonth, hour, minute, second,
> print(year, month, dayOfWeek, dayOfMonth, hour, minute, second, msec);
> 2012 7 4 9 12 39 15 910
> as output. So the month is 7 instead of the expected 8. So the month
> variable starts at 0 while all other variables start at 1.
> What's the purpose, or is it a bug? I use Fiji/ImageJ 1.46j.
> Thanks for help, Jürgen.
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html