Não use o campo post_date
para nada que não seja feito. Use um campo pós meta em vez disso. O post_date
é vinculado a post_date_gmt
, você teria efeitos colaterais estranhos, mesmo que você pudesse ter uma data anterior para isso.
Portanto, crie campos pós meta e consulte aqueles por consulta de impostos . Ignore o campo padrão.
Em resposta ao seu comentário: não use uma taxonomia.
- Taxonomias são construídas para permitir vários termos por postagem (ignorar pós-formatos aqui). O esquema não corresponde ao seu caso de uso.
- As consultas de taxonomia são caras, elas são executadas em três tabelas.
- Você teria que alterar a interface padrão para evitar acidentes, como várias atribuições. Possível, mas não exatamente simples e talvez não compatível com versões futuras.
Eu também iniciei um plugin para o gerenciador de livros, mas infelizmente ainda está em status de rascunho ... mas tenho algumas recomendações sobre datas:
-
Use dois tipos de postagem: um para o opus, um para as edições reais (o tipo
opus
seria pai de várias edições). Assim, você pode armazenar a data de criação no opus, a data de publicação (o idioma, o editor, o tradutor e assim por diante) na edição. -
Leia Tornando
<time>
seguro para historiadores . Datas anteriores a 1970 são difíceis. -
As Funções de data e hora do MySQL não pode lidar com todos os casos, você acaba com algumas rotinas personalizadas para classificação, dependendo da sua solução para (2.).