Solucionar problemas de data e hora em aplicativos baseados em modelo

Quando os valores de data e hora estão desativados por um dia ou algumas horas, isso pode ser causado por ajustes de fuso horário ou horário de verão. Este artigo fornece dicas para solucionar problemas como:

• O campo Data e Hora mostra o valor errado.
• O valor Somente data mostra a data errada para alguns usuários e fusos horários.
• O campo Data e Hora mostra o valor correto em algumas partes do aplicativo, mas não em outras.
• Depois de alterar um valor de data e hora e salvá-lo, ele muda automaticamente para um valor diferente.
• Inserir uma data de transição do horário de verão resulta na data de um dia ou de uma hora.

Determine se é um problema de servidor ou cliente

Aplicativos baseados em modelo são aplicativos Web. Eles obtêm dados do serviço de nuvem do Dataverse (servidor). Os mesmos dados podem alimentar vários aplicativos (clientes). Erros podem ocorrer no servidor ou no cliente.

Se o valor de data e hora armazenado no servidor for inesperado, ele provavelmente aparecerá incorretamente em todos os aplicativos, independentemente do fuso horário do usuário ou do sistema. Portanto, verificar o valor do servidor é um primeiro passo importante.

Verificar a configuração da coluna de data e hora

O Dataverse dá suporte a diferentes comportamentos de ajuste de fuso horário para colunas de data e hora (campos). Antes de solucionar problemas, é importante entender como diferentes partes do sistema processam valores de data e hora.

Verifique as opções de coluna de data e hora no portal do Power Apps ou no gerenciador de soluções:

• Se ele leva em conta o fuso horário de um usuário
• Se ele exibe a parte de tempo do valor

Verifique se o valor correto está armazenado no servidor

Os valores de data e hora são sempre armazenados como UTC no servidor. Você pode exibir o valor bruto no servidor com uma consulta de API Web.

Aqui está uma consulta para obter uma coluna para uma linha (registro).

[Organization URI]/api/data/v9.2/<entity set name>(<row id>)?$select=<column name>

Os nomes de tabela e coluna usados são nomes lógicos, não nomes de exibição.

O exemplo a seguir obtém a scheduledstart coluna da appointment tabela para a linha com ID d2862246-4763-ee11-8def-000d3a34118b.

https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart

Digitá-lo na barra de endereço do navegador mostrará algo como o seguinte:

{
    "@odata.context": "https://myorg.crm.dynamics.com/api/data/v9.2/$metadata#appointments(scheduledstart)/$entity",
    "@odata.etag": "W/\"11472725\"",
    "scheduledstart": "2023-10-15T07:30:00Z",
    "activityid": "d2862246-4763-ee11-8def-000d3a34118b"
}

Portanto, o scheduledstart appointment dia 15 de outubro de 2023, 7h30. O Z no final indica que o valor está em UTC.

Digamos que um usuário no fuso horário UTC-8 exiba essa coluna em um aplicativo baseado em modelo. Esses são os valores esperados para as diferentes opções de coluna.

Se o valor mostrado no aplicativo não for ajustado corretamente, é provável que seja um problema do cliente. Se o valor do servidor estiver incorreto para começar, provavelmente é um problema do servidor.

Verifique o valor formatado do servidor

Os ajustes de fuso horário e horário de verão podem ser feitos no servidor ou no aplicativo. Se a mesma coluna mostrar um valor diferente em diferentes partes do aplicativo, é provável que algumas partes do aplicativo estejam usando o valor formatado do servidor, enquanto outras estão fazendo os ajustes no aplicativo.

Isso provavelmente é um problema. Antes de relatá-lo, você pode isolar se é um problema de servidor ou cliente verificando o valor formatado do servidor.

Por exemplo,

GET https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart
Accept: application/json
OData-MaxVersion: 4.0
OData-Version: 4.0
Prefer: odata.include-annotations="OData.Community.Display.V1.FormattedValue"

A resposta incluirá o valor ajustado pelo servidor. Neste exemplo, o usuário está no fuso horário UTC-8 e scheduledstart tem comportamento Local do Usuário. Portanto, o valor formatado está oito horas atrasado em relação ao valor bruto.

{
    "@odata.context": "https://myorg.crm.dynamics.com/api/data/v9.2/$metadata#appointments(scheduledstart)/$entity",
    "@odata.etag": "W/\"11472725\"",
    "scheduledstart@OData.Community.Display.V1.FormattedValue": "10/14/2023 11:30 PM",
    "scheduledstart": "2023-10-15T07:30:00Z",
    "activityid": "2ad8786a-9164-ee11-9ae7-0022480a0700"
}

Se esse valor formatado estiver incorreto, é um problema do servidor. Se estiver correto, então é um problema do cliente.

Investigar valores inesperados do servidor

Os possíveis motivos para valores de servidor inesperados são:

• Talvez você não tenha configurado o comportamento e o formato do ajuste de fuso horário corretamente.
• As regras de negócios e os fluxos de trabalho em execução no servidor podem alterar o valor antes ou depois de serem salvos. Dentro de um aplicativo, os scripts do cliente podem alterar o valor antes de enviá-lo ao servidor para salvar.

Determine se é um problema de personalização ou de produto

As personalizações podem levar a um comportamento inesperado. Os métodos a seguir podem ajudar a descartar problemas causados por personalizações.

Desabilitar scripts personalizados

Os scripts personalizados frequentemente causam problemas. Tente desativá-los temporariamente.

Criar uma nova coluna de data e hora

Criar uma nova coluna de data e hora é a maneira mais fácil de descobrir se o problema é causado por erros de configuração ou personalizações, como regras de negócios. O ideal é usar uma tabela e um aplicativo diferentes.

Se a nova coluna funcionar conforme o esperado, é provável que seja um problema de personalização. Compare com a coluna original para encontrar a diferença.

Se a nova coluna tiver o mesmo problema, pode ser um problema do produto. Você pode criar um aplicativo baseado em modelo de reprodução básica e relatá-lo por meio de uma solicitação de suporte.

Tente um fuso horário diferente

Para descobrir se os ajustes de fuso horário e horário de verão estão causando valores inesperados, tente alterar o fuso horário do usuário.

Há duas configurações que afetam os fusos horários em aplicativos baseados em modelo:

1. Fuso horário nas opções pessoais.
2. Fuso horário do sistema. Para obter informações sobre como alterá-lo, consulte a respectiva documentação no Windows, Android, iOS ou macOS.

Combinações úteis para experimentar:

• Combine o fuso horário nas opções pessoais com o fuso horário do sistema.
• Use o fuso horário UTC.
• Use um fuso horário com o mesmo deslocamento, mas não observe o horário de verão.

Altere o formato "Somente data" para "Data e hora"

Se um valor somente de data estiver desativado em um dia, é útil mostrar a parte da hora para ver se os ajustes de fuso horário podem ser a causa. Você pode alterar temporariamente o formato da coluna no portal do Power Apps ou no gerenciador de soluções.

Não use anos de 2 dígitos

O ano de 2 dígitos é ambíguo. Por exemplo, 40 pode significar 1940, 2040 ou 2140. A forma como o sistema interpreta os anos de 2 dígitos pode e provavelmente mudará com o tempo.

Também é difícil investigar quando os valores completos de data e hora não são mostrados. Por esses motivos, é altamente recomendável usar anos de 4 dígitos, especialmente ao inserir datas.

Se você não conseguir mudar para anos de 4 dígitos permanentemente, tente temporariamente para ajudar a solucionar o problema.

Confira também

Comportamento e formato da coluna de Data e Hora