Recentemente, tive um problema em que nosso cliente tem uma lista de eventos (implementada como uma visualização simples do Drupal) e os campos de data de início / término do conteúdo são exibidos corretamente na visualização de lista, mas incorretamente no modelo de nó personalizado que usamos para exibir o completo nó desse evento.
Por exemplo, haveria um curso acontecendo em 3 de fevereiro. Ele apareceria como tal na Visualização, mas seria mostrado como 4 de fevereiro na página de detalhamento personalizado.
Esta página de detalhamento personalizada é algo que um membro da equipe criou como uma visualização, mas usou um campo PHP global para realizar alguma lógica específica sobre como exibir alguns outros dados associados à data em vez de um campo “data”. Como eles usaram o PHP Global, ele não se comportou da mesma maneira que o campo de data pronto para uso em uma visualização.
O que é pior, é que isso aconteceu apenas para alguns nós, e não todos eles.
Acabei percebendo o seguinte:
Ao usar campos de data prontos para uso em uma visualização do Drupal, você não precisa se preocupar em levar em consideração a diferença de tempo entre o fuso horário do servidor e o fuso horário associado ao campo de data. O Drupal cuida disso para você.
Os nós culpados foram todos criados um pouco perto da meia-noite, portanto, foram tratados como 3 de fevereiro pela visualização de lista, mas 4 de fevereiro pelo código personalizado, porque não havia reconciliação dos fusos horários.
Você precisa especificar o fuso horário do banco de dados ao converter a string em hora e, em seguida, usar o fuso horário do campo ao executar a função date_format. Ver abaixo:
(Para entender a importância dos parâmetros, você pode consultar a API Drupal aqui)
$date_converted = strtotime($date[0]['value'].' '.$date[0]['timezone_db']);
print format_date($date_converted, 'custom', 'j M Y', $date[0]['timezone']);Por meio do uso da página API e de um artigo maravilhoso do StackExchange , fui capaz de raciocinar e resolver a discrepância.