In Plone 2.1 (don't know about other versions) the default date input used by the
CalendarWidget uses 5 dropdowns (year, month, day, hour, minute) plus a little popup calendar which you can use to avoid flipping the dropdowns. When the underlying value is not set the dropdowns look like this:
2007/--/-- [#] --:--
where the little
[#] is the popup calendar widget. The year 2007 is preselected because they assume that most of the cases you'll just be selecting a month and a day since is highly likely that the year will be that of today's year. So far so good.
The problem is that people get confused. Where I'm doing some consulting work at the moment two people have "complained" that news items expire because the year is set to 2006 or 2007 or whatever is today's year. I assured them that it's built like that to save you (in most cases) the additional click of selecting the year. But even if I could convince these people of the motorical economics of the default year, they still found it confusing and so much on behalf of other people who might end up thinking the same thing.
So we decided to change the default to be just:
----/--/-- [#] --:--
and I must admit that this looks cleaner and makes it more immediately obvious that the date hasn't been set.
Lesson learnt: Don't take too many shortcuts just to save a few clicks. Stand back and think about what impressions a widget can give visually about it's functionality and value.
I guess Peter's point is something else though: Taking the shortcut may take longer.
I solved that problem once with a "clever date input" field where they could basically type anything they like and my parsed just did the best it could. Here were some possible formats: "1st Jan", "june", "2005/1/2", "14 september 2006" etc.
However, this was a UK only site and if a US person would use it she'd have to accept the UK standard but you could treat ambiguous formats just like you'd have to treat impossible ones like "34 dec 2007"