Não consigo definir o ano abaixo de 1899 para um cargo. Se eu definir o ano abaixo de 1899, ele será definido para o ano atual automaticamente.

Comprei o tema Linha do tempo e perguntei no fórum de suporte. Eles responderam:

Isso soa como uma limitação criada pelo seu provedor de hospedagem. Nada no tema está impedindo a data que você atribui - como você pode ver, a demo tem postagens usando datas nos anos 1400. Tente entrar em contato com seu provedor de hospedagem e veja se eles têm alguma ideia de como lidar com isso.

Isso não é realmente uma resposta, apenas uma tentativa de encontrar o contexto específico para esse problema. Instale o seguinte plugin no seu site, tente definir as três datas e adicione seu resultado ao segundo <pre>na tabela abaixo.

/* Plugin Name: WPSE Sysinfo */
add_action( 'admin_footer', 'wpse_sysinfo' );
function wpse_sysinfo() {

    $bit         = 4 === PHP_INT_SIZE ? 32 : 64; // PHP version, not OS!
    $php_version = PHP_VERSION;
    $db_version  = $GLOBALS['wpdb']->db_version();

    print "<pre>$bit | $php_version | $db_version</pre>";
}

A essência do plug-in pode ser conferida aqui .

OS Bit OS | PHP Bit PHP | MySQL 999 1899 2020 2039 do utilizador

WIN7 64 5.4.4 ?? | 5.5.25 ✘ ✘ ✔ | ✘ toscho
Linux ?? | 5.3.18-nmm1 | ?? | 5.1.70 ✔ | ✔ | ✔ | ✔ | toscho
CentOS 6 | 64 5.5.4 ?? | 5.0.95 ✔ | ✔ | ✔ | ✔ | toscho
WIN7 64 5.4.15 32 5.5.31 ✘ ✘ ✔ | ✘ raramente
Ubuntu 12.04 | 64 5.3.10-1 64 5.5.32 ✔ | ✔ | ✔ | ✔ | Pille
CloudLinux | 64 5.2.17 64 5.0.96 ✔ | ✔ | ✔ | ✔ | Pille
Ubuntu 12.10 | 64 5.4.6 64 5.5.32 ✔ | ✔ | ✔ | ✔ | Michael Ecklund
CENTOS 5.9 | 32 5.3.27 32 5.5.32 ✘ ✘ ✔ | ✘ Michael Ecklund
WIN7 64 5.4.7 64 5.5.27 ✘ ✘ ✔ | ✘ kaiser
OSX 10.7.5 | 64 5.3.6 64 5.5.9 ✔ | ✔ | ✔ | ✔ | GhostToast
Centos 6.4 | 64 5.4.17 32 5.1.59 ✘ ✘ ✔ | ✘ Birgire
Debian 6 | 64 5.4.19 64 5.1.66 ✘ ✘ ✔ | ✘ Birgire
WIN7 64 5.5.0 64 5.5.22 ✘ ✘ ✔ | ✘ GM
OSX 10.7.4 | 64 5.3.6 64 5.5.9 ✔ | ✔ | ✔ | ✔ | brasofilo
CentOS 5 | 64 5.3.22 64 5.1.68 ✔ | ✔ | ✔ | ✔ | brasofilo
Mac 10.8.5 | 64 5.3.26 64 5.5.25 ✔ | ✔ | ✔ | ✔ | flentini
WIN7 64 5.3.27 64 5.5.31 ✔ | ✔ | ✔ | ✔ | Sascha Krause
Win7SP1 64 5.3.8 64 5.5.28 ✔ | ✔ | ✔ | ✔ | Manuel Sychold

1. Crie uma nova postagem. Salve isso.
2. Defina a data como 1º de janeiro 0999, clique em Atualizar . Ele foi salvo ou alterado para a data atual?
3. Repita para as configurações de data para 1899, 2020e 2039.
4. Pegue as informações da saída do plug-in no rodapé do administrador e atualize a tabela.

Pergunta e expectativas

Embora a forma literal desta questão seja prática no contexto (ano de 1899), é um pouco vaga no sentido teórico. Quantos anos tem a idade? Até onde no passado podemos querer ir? E o futuro?

Desde que o WordPress começou como mecanismo de blog, nesse sentido contextual , ele evoluiu para lidar com o seguinte período de tempo:

• datas em que o WP existia (obviamente, para poder usá-lo)
• gama de possíveis postagens históricas (implicitamente já na Internet)
• o mais longe possível no futuro, sem esforço especial (trabalhe até que se quebre)

À medida que o uso do WordPress evoluiu para aplicativos que não são de blog, esses projetos (geralmente história e arte, como eu já vi nos relatórios) começaram a atingir vários problemas com datas fora desse período.

Para o propósito de minha pesquisa, formulei as seguintes perguntas:

1. Quais são os dois primeiros e mais recentes anos civis completos, que podem ser usados ​​com as datas de postagem do WordPress de forma nativa e confiável?
2. O que são frutas baixas (se houver) para estender a extensão disponível além da faixa nativa?

Limitações da plataforma

Como o WordPress é um aplicativo PHP e usa o MySQL para armazenamento de dados, está sujeito às suas limitações.

MySQL

O WordPress armazena as datas de postagem na post_datecoluna do DATETIMEtipo no MySQL.

De acordo com a documentação, esse tipo suporta os anos 1000 a 9999 :

O DATETIMEtipo é usado para valores que contêm partes de data e hora. O MySQL recupera e exibe DATETIMEvalores em 'YYYY-MM-DD HH:MM:SS'formato. O intervalo suportado é '1000-01-01 00:00:00'para '9999-12-31 23:59:59'.

No entanto, também diz que valores anteriores podem funcionar, sem menção de valores posteriores:

Para as DATE and DATETIMEdescrições de intervalo, "suportado" significa que, embora os valores anteriores possam funcionar, não há garantia.

Embora empiricamente eu tenha observado valores fora do intervalo de trabalho, isso é anedótico e fica fora da nossa condição de confiabilidade.

PHP

Na programação PHP, a representação de data e hora do Unix é amplamente usada. De acordo com a documentação para nossos propósitos (PHP 5.2+ e ambiente genérico de 32 bits), ele suporta os anos (na íntegra) de 1902 a 2037 :

O intervalo válido de um carimbo de data / hora é tipicamente de Fri, 13 Dec 1901 20:45:54 UTCaté Tue, 19 Jan 2038 03:14:07 UTC. (Essas são as datas que correspondem aos valores mínimo e máximo para um número inteiro assinado de 32 bits.) Além disso, nem todas as plataformas oferecem suporte a carimbos de data e hora negativos, portanto, o período pode ser limitado a não mais cedo do que a época do Unix. Isso significa que, por exemplo, datas anteriores a Jan 1, 1970não funcionarão no Windows, em algumas distribuições Linux e em alguns outros sistemas operacionais. O PHP 5.1.0 e versões mais recentes superam essa limitação.

Além disso, o Date/Timemanuseio mais recente é de 64 bits e varia de aproximadamente -292 a 292 bilhões de anos , o que provavelmente excede as necessidades da humanidade no momento.

Limitações do WordPress

O WordPress introduz e herda algumas limitações adicionais em sua base de código.

Fluxo de dados

Do ponto de vista básico do fluxo de trabalho do usuário, existem dois processados ​​relacionados à data:

• A entrada de data no formulário pós-edição deve ser corretamente processada e salva no banco de dados
• A data salva no banco de dados deve ser corretamente lida e mostrada na interface

Observe que esses são processos tecnicamente completamente diferentes e independentes. Como explicado mais detalhadamente, seus intervalos não se sobrepõem e salvar a data correta não é igual à capacidade de lê-la corretamente no ambiente do WordPress.

Limites explícitos

• O editor de postagem do WordPress em admin permite um intervalo de anos, que pode ser enviado como data de postagem, de 100 a 9999
• _wp_translate_postdata() processa o ano (enviado como número distinto do formulário) e:
  • desinfeta para não-negativo > 0
  • valida usando wp_checkdate(), que chama PHP nativo checkdate(), que impõe limite de 1 a 32767

Limites implícitos

• strtotime()A função PHP é usada várias vezes e está sujeita ao carimbo de data e hora do Unix acima mencionado, no nível mais baixo mysql2date()que afeta todas as leituras de datas do banco de dados, intervalo herdado de 1902 a 2037
• O WordPress volta à expressão regular para a análise de datas get_gmt_from_date(), que espera que o ano seja ([0-9]{1,4}), limitando de 1 a 9999 , forte possibilidade de processamento semelhante em outras funções que exigirão que uma auditoria de código mais completa seja enumerada

Possibilidade de soluções alternativas

• wp_checkdate()possui wp_checkdatefiltro, o que permite substituir essa verificação de validação
• a saída destinada ao usuário final através da date_i18n()qual possui date_i18nfiltro, teoricamente permite interceptar e reprocessar completamente a saída de datas para fazer a interface, por mais desafiador que seja se a função já for ultrapassada (fora da faixa ( false))

Conclusões

Para propósitos práticos e portabilidade dos dados, o período de postagem do WordPress parece ser igual ao carimbo de data e hora do Unix de 32 bits e consiste nos anos de 1902 a 2037, inclusive .

Para qualquer operação pós-data fora deste intervalo, o ambiente deve ser auditado (intervalo de 64 bits de registros de data e hora Unix, MySQL funcionando de fato ou armazenamento de banco de dados alternativo para os valores). Para intervalos maiores ( abaixo de 1000, acima de 9999 ), é provável que sejam necessárias quantidades consideráveis ​​de código personalizado.

Para qualquer implementação de datas arbitrárias, faz sentido:

• armazená-los no MySQL em formato não sujeito a limitações do banco de dados
• processo em PHP usando Date/Timecódigo completamente personalizado e / ou funções do WordPress auditadas para não serem afetadas pelos limites de carimbo de data / hora do Unix

Cama de teste de código

O código a seguir e o conjunto de anos escolhido a dedo foram usados ​​para a pesquisa acima e o teste de conclusões:

require ABSPATH . '/wp-admin/includes/post.php';

$timestamp_size_info = array(
    'PHP_INT_SIZE'   => PHP_INT_SIZE,
    'PHP_INT_MAX'    => number_format( PHP_INT_MAX ),
    'min timestamp'  => date( DATE_ISO8601, - PHP_INT_MAX ),
    'zero timestamp' => date( DATE_ISO8601, 0 ),
    'max timestamp'  => date( DATE_ISO8601, PHP_INT_MAX ),
);

r( $timestamp_size_info );

// hand picked set of years to test for assorted limits
$years = array(
    'negative'           => - 1,
    'zero'               => 0,
    'one'                => 1,
    'wp min'             => 100,
    'mysql first'        => 1000,
    'before unix'        => 1899,
    'unix first'         => 1902,
    'current'            => 2013,
    'unix last'          => 2037,
    'after unix'         => 2039,
    'mysql last, wp max' => 9999,
    'after checkdate'    => 33000,
);

// simulates form submission data
$post = array(
    'post_type' => 'post', // shut notice
    'edit_date' => 1,
    'aa'        => 1,
    'mm'        => '01',
    'jj'        => '01',
    'hh'        => '00',
    'mn'        => '00',
    'ss'        => '00',
);

// add_filter( 'wp_checkdate', '__return_true' );

foreach ( $years as $name => $year ) {

    $post['aa'] = $year;
    $translated = _wp_translate_postdata( false, $post );

    if ( is_wp_error( $translated ) ) { // wp_checkdate() failed
        r( array( 'year' => $year . " ({$name})", 'translated valid' => false ) );
    }
    else {

        $post_date        = $translated['post_date'];
        $post_date_gmt    = $translated['post_date_gmt'];
        $translated_valid = (string) $year == substr( $post_date, 0, strpos( $post_date, '-' ) );
        $mysql2date       = mysql2date( DATE_ISO8601, $post_date );
        $mysql2date_valid = (string) $year == substr( $mysql2date, 0, strpos( $mysql2date, '-' ) );

        r( array(
            'year'             => $year . " ({$name})",
            'post_date'        => $post_date,
            'translated valid' => $translated_valid,
            'post_date_gmt'    => $post_date_gmt,
            'mysql2date'       => $mysql2date,
            'from sql valid'   => $mysql2date_valid,
        ) );
    }
}