At first there was simply a date format field.

  • Problem: it was not possible to indicate dates for which the exact month and day was unknown. It would just fill in a day and month- usually the day and month of the edit.

An approximate year and approximate month was added.

The year and month field was thereafter derived from the date field, and guaranteed to exist.

  • Some contributors set the year and month parameters or form fields not understanding the parameters would be ignored if date was present.
  • A form entry for a date has a bewildering number of boxes to fill out to specify a date.
  • SMW forms pick lists for date fields are not localized. EG, if user preference is spanish, the month list still gives January, February, etc.


  • Internationalize month input by using numbers for months. (SMW forms date inputbox did not support alternate languages).
  • keep the date components separate. year, month, day, hour (24hour), minute. With BCE checkbox. Times are (GMT/UTC)
    • Example scenarios for hour/minute: birth date/time since horoscope folks seem very interested in this. A sequence of events in a battle or at a long event like a wedding would require hours and minutes for a proper timeline to be constructed.
  • Eliminate date and date-time entry values on form as well as the corresponding parameters. Hereafter, the date is assembled from the components. A full date parameter is no longer accepted.
  • Docs clarification: Omitting day does not imply circa. For instance, "Circa November 1941" could mean October or December if Circa is clicked. If not, then this means that the event definitely happened in November, but the exact day is not specified.
  • For reports to return results sorted by date, if a record does not have some sort of date field it will be omitted. A bogus year will have to be supplied for records for which the year is unknown. SMW date type allows Month and or day values to be omitted, even though SMW forms autofill them. Since a year can be assigned which is obviously bogus (eg: 9999) then the field with this bogus value can be displayed. (Previously, it was thought we might use a date_sort_key field that would only be used for sort and search and also had bogus month and day values. Since day and month bogus values are not needed, this idea has been shelved for the more simple single assembled date field.)