Do not use the
post_date field for anything it isn’t made for. Use a post meta field instead. The
post_date is bound to
post_date_gmt, you would get strange side effect even you could get an earlier date into that.
So create post meta fields and query those per tax query. Ignore the default field.
In answer to your comment: Do not use a taxonomy.
- Taxonomies are build to allow multiple terms per post (ignore post-formats here). The scheme does not match your use case.
- Taxonomy queries are expensive, they run through three tables.
- You would have to change the default interface to prevent accidents like multiple assignments. Possible, but not exactly simple and maybe not forward-compatible.
I started a book manager plugin once too, unfortunately it is still in a draft status … but I have some recommendations regarding dates:
Use two post types: one for the opus, one for the real editions (the
opus type would be a parent for multiple editions). So you can store the creation date in the opus, the publication date (the language, the editor, translator and so on) in the edition.
<time> safe for historians. Dates before 1970 are hard.
The MySQL Date and Time Functions cannot handle all cases, you end up with some custom routines for sorting, depending on your solution for (2.).