Sure enough. But is it a sane thing to do for a "convert readable date to date object" function to silently amend the current day-of-month to a otherwise underdpecified date?

I really don't see the use case for that anywhere.

I would expect to use the first day of a month as a default, just like when time is not specified it should use 00:00 as default. Taking the current time/day as a default sounds off.

Probably hard to fix backwards compatible though...

Agreed; I expect date parsers to give me earliest-available value for a field if it's not specified, with the exception being the current year rather than 0 AD or whatever.

Javascript:

    new Date("Feb 2006")
    > Wed Feb 01 2006 00:00:00 GMT-0800 (Pacific Standard Time)

Ruby:

    require 'time'
    Time.parse "Feb 2006"
    => 2006-02-01 00:00:00 -0700

According to the documentation there's a 'default' parameter, which contains the datetime used to get otherwise unspecified fields. If not given, the default is the current date. Thus to get what you want:

    >>> from datetime import datetime
    >>> from dateutil import parser
    >>> now = datetime.now()
    >>> first = datetime(now.year, now.month, 1, 12, 0, 0)
    >>> dateutil.parser.parse('February 2006', default=first)
    datetime.datetime(2006, 2, 1, 12, 0)

Exactly, not sure how much code has been written to take advantage of this fact. Taking day 1 is a much safer option definitely.

Moreover, often this is not what you want. Generally you'll want either "the last past day that had that number" (logging of activity), or "the first future day that has that number" (appointment planning). But having a date that can be randomly in the past or the future sounds a bit strange.