and i feel like an idiot. didn't realize that today was the 4th. i would imagine that June 1 would make more sense though...but thats pretty nit picky.

I guess it's hard to give an answer to an ambiguous input that will please everyone. Personally I would have expected the 1st of the month.

It seems unusual that "next June" and "last June" both pick the 4th of the month (today's date); but just "June" gives the 1st of the month.

Also "next June" gives "Friday, June 04, 2010 12:00:00 AM" so it picks the day of the month based on today; but the time of day doesn't depend on the time now.

my (available on the mailing list but not integrated) patch for the library gives you a callback into just that point in the process where the library has parsed out what it can but hasn't filled in defaults yet, so you can insert the assumptions that make sense for your application and not have to rely on the default ones.

This is the test I use on all date libraries I come across. I don't know what the right answer is, I just want it to be logical:

(pseudo) Date d = new Date('1/31/2009'); d.addOneMonth();

What is the value of d? 2/28/09? 3/2/09? 2/25/09?

Writing a date library is not for the fainthearted.

IT SHOULD NOT PICK A DAY! It should return (2010, 6) -- with no precision implied beyond the input.

This is a major personal hobby-horse of mine, and I don't know of a library that does all of what I want by default. The constructor for datetime in Python's standard library comes very close:

  datetime(year, month, day[, hour[, minute[, second[, microsecond[,tzinfo]]]]])

All of the time components have no implied precision beyond the input you've given -- "2009-06-04 3pm" is never implicitly upcast into "2009-06-04 15:00:00 UTC". This is awesome.

Unfortunately the date object used internally does not allow for partial precision, so datetime doesn't expose it.