[resoluteteeth]

> This is perhaps the weakest of the objections, it has been done and it could be doable, if we wanted it.

It's not at all a weak objection. I mean, sure, months are arbitrary in the first place and it's not physically impossible to set up a system where there are days outside of months. A system set up that way might not be any more complicated than our current system since it would simplify other aspects of dates. But making that change would fundamentally break a lot of our assumptions about dates in ways that would require a ton of effort to fix (good luck getting any existing software dealing with dates to work properly after that) for very little benefit, so it's an incredibly bad idea.

The article also says that the extra days wouldn't even be assigned days of the week, which is even worse.

[kevincox]

Getting existing software to change is equivalent to the general switching cost problem which is the real argument.

Software modeling would be easy. For software it is an additional month with only 1 or 2 days. However because it would be a holiday most humans wouldn't need to talk about it as a month.

[resoluteteeth]

> Software modeling would be easy. For software it is an additional month with only 1 or 2 days.

You will also have to consider actions that are performed on the first of the month and possibly special case these months. This also means that effectively you have just made the length of months even more variable and confusing.

It's really only "easy" in the sense that it is possible to fit it into existing date data structures, but it's not necessarily that "easy" in terms of updating business logic.

> However because it would be a holiday most humans wouldn't need to talk about it as a month.

It can't be a holiday for everyone and it will still need to be something that people think about. Hospitals, fire departments, police, and websites that are expected to operate 24/7 will still need to operate and handle the special day. It will probably also need to be a new special case in literally every contract (leases, employment contracts, billing terms, etc.).

The human aspects are perhaps even harder than the computer aspects because it won't be possible to simply think of it as a 1 day month, it will HAVE to be special cased.

The original article also said that the extra day would not be assigned a day of the week. This is even more confusing. Currently, every 7 days is one week regardless of years, but if this change is made, for any action that needs to be performed once every seven days, either a decision will have to be made on whether 1) to perform/not perform the action on the special day depending on what day it WOULD have been if it wasn't the special day and then shift the day of the week for the next year, or 2) allow an interval of 8-9 days once a year.

Even though there is currently a slight inconvenience from 1) months having different numbers of days and 2) days of the week not being the same every month, these reflect the realities that months are arbitrary and don't match up to solar years/days.

The proposed change is actually arguably worse because it has to add even more complexity in the form of edge cases to try to pretend these problems don't exist.