There’s also nothing wrong with using an integer or UUID PK as an additional field even on a table that has another field that would make a natural primary key.
Date as primary key is a pattern sometimes used in star schemas for OLAP databases, though separate y/m/d tables are more common afaik.
- Unique
- Irreducible (i.e. no part of the candidate key also qualifies as a primary key)
- Stable (does not change over time)
- Simple (a built-in type of the database engine qualifies)
So, yes, a date meets the requirements.
In a properly normalized schema all of the attributes (fields, columns) in the relation (row) depend on the primary key.
You describe a table for a newsletter published no more than once per day. In that case the date makes a good primary key.
Note that a date value for primary key is logically equivalent to an auto-incrementing integer surrogate key, assuming uniqueness holds (one newsletter per day). The advantage of the date is that it means something, whereas a surrogate key has no meaning, it exists only to satisfy the uniqueness requirement (and often indicates something went wrong when normalizing the schema).
If you might ever post revisions on the same day and want to indicate that you would have to add that information to the primary key, e.g. (published-on DATE, revision INT) to maintain uniqueness.
Date, date/time, and timestamp attributes either implicitly or explicitly refer to a specific timezone. That may or may not matter in your case (I suspect it doesn't), but timezone conversions and confusion give one reason a date or date/time value may not make a good key.
It would be best for indexing to store the actual value in binary, though not strictly necessary as these later UUID standards (unlike conventional UUIDs) use time code prefixes (so indexing clusters.)