Adam Bien's Weblog
Month or MonthOfYear? - participate in the naming of the New Date and Time (JSR-310)!
The New Date And
Time (JSR-310) targeted for JDK 1.7 will provide an object oriented - fluent
API, in contrary to currently available java.util.Date and
java.util.GregorianCalendar. However we are discussing now different naming
options, which are summarized here. The first option is more consistent and uses a generic scheme (a context) for the naming of the classes. The second option is shorter, more fluent but not always consistent. So what do you prefer? Participate in the discussion and influence one of the core JDK 1.7-APIs!
Posted at 07:43AM Nov 20, 2007 by Adam Bien in Java / JEE / Architecture | Kommentare[6]
[my tweets]
Rss My book: Real World Java EE - Rethinking Best Practices


I think I prefer the second option becasue the names are shorter. But an important thing missing from this discussion is the arguments, in January month=0 or month=1, is year 2007 or 107 (to denote 2007). Frankly, I have never understood why sensible defaults such as 1=january, 2007 = year 2007 etc. has never been enforced before. Also the whole clutter about 24 hour times where hours can be 0-23 or 1-24... this is really confusing, as eg. hour "16" you don't know if this is 4 pm or 3pm (depending on 0-23 or 1-24 hour format is used).
In conclusion, use sensible arguments and sensible defualts. I think this is far more important than the wording of the method names (now that the suggested alternatives are so closely related).
Dr. Kasper Graversen
Gesendet von kasper Graversen am November 21, 2007 at 01:36 PM CET #
JSR-310 will use January=1, December=12, year 2007=2007, and hours from 0 to 23.
Gesendet von Stephen Colebourne am November 21, 2007 at 04:03 PM CET #
Option 1 is very clear. Dr. Graversen, I think that clarity is much more important than brevity. In fact, I think that brevity is the least important attribute of any name in java.
Option 1 increases readability, understandability, and therefore reliability, and modifiability. Be shorter names hinder all of these software development goals.
Gesendet von Mike am November 21, 2007 at 05:09 PM CET #
I am for option 2 if DayOfMonth would be refactored to Day (if not than option 1).
If we are talking about seconds, minutes, days, month, years everyone has already the correct bounding unit in mind.
>JSR-310 will use January=1, December=12, year 2007=2007, and hours from 0 to 23.<
month are starting at 1 and hours at 0?
what about minutes and seconds or are hours the sole exception?
Gesendet von Michael Bien am November 21, 2007 at 07:40 PM CET #
Clarity is more important than brevity, but there's no need to go overboard. I'd go for option 2 as well, using 'Day' instead of 'DayOfMonth' and 'Weekday' instead of 'DayOfWeek'. Not sure that you need 'MinuteOfDay' since it's easily calculated (hour * 60 + minute) and probably not often required. Likewise HourOfMeridiem. If you want to include every conceivable option, you'll need a boolean (or an enum if you prefer) specifying the meridiem.
Gesendet von Andy am November 22, 2007 at 05:29 PM CET #
I think Option2 is the more direct than going on being redundant in the explanation of names for second minute, etc.
Gesendet von sujal am February 27, 2008 at 01:22 PM CET #