Comments (9)
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.
Related Issues (20)
- NT 2023.001 nova nota tecnica
- NT 2023.001 nova nota tecnica HOT 1
- CT-e Manual de Orientação do Contribuinte - Visão Geral - Versão 4.0 - fevereiro/2023
- Erro ao ler XML com <pBio> na classe NFNotaInfoItemProdutoCombustivel HOT 2
- Alteração do retorno do cancelamento
- Adequação SOAP 1.2 - SEFAZ MG HOT 6
- Atualização axis2 de 1.6.4 para 1.7.9 HOT 6
- Cancelamento Extemporâneo NF-e - Rejeição 573: Duplicidade de Evento
- Link CTe QRCode SEFAZ MG
- Atualizacão axis2 de 1.7.9 para 1.82 HOT 12
- Emissão de NFC-e com Certificado A3 HOT 5
- Link CTe QRCode SEFAZ MG - V4
- Erro stax2-api HOT 2
- XML NFe nulo HOT 1
- NullException quando tento fazer o envio do lote HOT 3
- Alterações para NT 2023.004 e 2019.001 HOT 1
- Valor "perdido"no xml do protocolo de entrega HOT 3
- Nova cadeia de certificados Sefaz/MS HOT 5
- Correção na geração do XML da NFNotaInfoItem conforme NT 2021.004 v1.32 HOT 1
- Desativação do Serviço Assíncrono do MDFe HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nfe.