Problema com LocalDateTime about nfe HOT 9 CLOSED

Parece ótimo, Felipe!
Você tem condições de criar um PR com essa sua idéia? Consegue anexar ao
menos um teste unitário validando sua teoria?
Isso parece resolver um problema que mais usuários podem enfrentar, então
ficaríamos contentes em poder corrigi-la no projeto!
No aguardo.
Att,
Diego

2016-02-15 15:58 GMT-02:00 Felipe Leonhardt [email protected]:

Boa tarde pessoal,

Imaginem o seguinte quadro:
Um cliente solicita o envio de Nota com data/hora de emissão em Cuiabá
porém o servidor que envia a nota está em Brasília.
Segundo a documentação do JodaTime a classe LocalDateTime é uma informação
de Data/Hora sem TimeZone.

Estamos tendo problemas com essa classe nesse quadro, porém utilizando a
classe DateTime(JodaTime) o problema é resolvido pois ao converter a data
ele preserva o TimeZone.

O problema maior e que compromete é que na classe
NFLocalDateTimeTransformer no método write temos um data.toDate() que
converte em um java.util.Date que possui o timezone local do S.O.

Minha sugestão de alteração seria:
1 - Alterar todos os LocalDateTime para DateTime(JodaTime que preserva a
informação do TimeZone);
2 - Modificar a classe NFLocalDateTimeTransformer para
NFDateTimeTransformer
3 - Alterar o método read()... para:
private static final DateTimeFormat format =
DateTimeFormat.forPattern("yyyy-MM-dd'T'HH:mm:ssZ");
public DateTime read(final String data) throws Exception {
return format.withOffsetParsed().parseDateTime(data);}

4 - Alterar o método write()... para:
public String write(final DateTime data) throws Exception {
return data.toString(format); }

Essa alteração não compromete a atual implementação, porém resolve a
situação de utilizar o projeto de vocês em servidor de envio centralizado
com TimeZone diferente da aplicação de envio de origem.

O que acham?

—
Reply to this email directly or view it on GitHub
#113.

from nfe.

Obrigado Diego pela rápida resposta,

Vou realizar as alterações e criar os testes.

from nfe.

Boa tarde a todos, só para registrar uma ideia....
Se a LocalDateTime ignora o timezone, o horário a ser enviado, será o horário passado pelo Client, correto? Já que não há timezone, o horário enviado para o sefaz será o mesmo do Client.

Qual seria o problema?

from nfe.

Quando o aplicativo está no cliente não há problema, o problema ocorre quando temos uma requisição de envio por um timezone diferente de onde está o software de envio e que na classe NFLocalDateTimeTransformer temos um data.toDate() que converte em um java.util.Date que nele naturalmente possui um TimeZone do S.O local e ao transformar em String fica o timezone local.

from nfe.

Entendi! Entao quando ele passa para o sefaz, o server serializa a data com o timezone junto.. achei que ele ignorava o timezone e serializava apenas a datahora.

Enviado do meu iPhone

Em 15 de fev de 2016, às 17:10, Felipe Leonhardt [email protected] escreveu:

Quando o aplicativo está no cliente não há problema, o problema ocorre quando temos uma requisição de envio por um timezone diferente de onde está o software de envio e que na classe NFLocalDateTimeTransformer temos um data.toDate() que converte em um java.util.Date que nele naturalmente possui um TimeZone do S.O local e ao transformar em String fica o timezone local dando rejeição na Sefaz.

—
Reply to this email directly or view it on GitHub.

from nfe.

Sim, se você observar o XML gerado é gerado com o TimeZone e no Manual do Contribuinte eles pedem que seja enviado no formato com o TimeZone.

from nfe.

aí vai dar problema mesmo! valeu pela explicaçao

Enviado do meu iPhone

Em 15 de fev de 2016, às 18:30, Felipe Leonhardt [email protected] escreveu:

Sim, se você observar o XML gerado é gerado com o TimeZone e no Manual do Contribuinte eles pedem que seja enviado no formato com o TimeZone.

—
Reply to this email directly or view it on GitHub.

from nfe.

Pessoal, boa tarde, tudo bem?

Corrigi um problema localmente com a classe NFLocalDateTimeTransformer.

Ela possui como atributo de classe um SimpleDateFormat static e o mesmo não é threadsafe (JE7), estava enfrentando picos de 1 nota fiscal em média de 600ms e estava tento erros de ponto flutuante.

A correção foi simplesmente alterar as linhas:

`private static final SimpleDateFormat SIMPLE_DATETIME_FORMATTER = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");

private static final SimpleDateFormat DATETIME_FORMATTER = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssXXX");`

Para:

SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssXXX"); fromDateFields = LocalDateTime.fromDateFields(simpleDateFormat.parse(data));

Sugiro avaliarem outros locais que utilizam statics com Objetos que não são threadsafe, ou usar new ou optar por syncronized no acesso desses objetos caso desempenho não seja considerado.

Na minha versão, o método ficou da seguinte maneira:

try {
			SimpleDateFormat dateTime = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
			fromDateFields = LocalDateTime.fromDateFields(dateTime.parse(data));
			
		} catch (ParseException e) {
			SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssXXX");
			fromDateFields = LocalDateTime.fromDateFields(simpleDateFormat.parse(data));
			
		}

Obrigado,
Att

from nfe.

Pessoal, encontrei inúmeras ocorrências do mesmo problema, sugiro abrir issue.

Att

from nfe.