search

ZeusAutomacao / DFe.NET

Biblioteca para Geração de NFe(2.0, 3.10 e 4.0) e NFCe(3.10 e 4.0) e consumo dos serviços necessários à sua manutenção, conforme descritos em http://www.nfe.fazenda.gov.br/portal/principal.aspx
GNU Lesser General Public License v2.1
754 stars 476 forks source link

DateTime para DateTimeOffSet #570

Closed bruno-alencar closed 6 years ago

bruno-alencar commented 7 years ago

Estava olhando a parte de datas do nfeProc e notei que todos os campos estão como DateTime.

Desta forma, usa-se o TimeZone da máquina para conversão do DateTime para DateTimeOffSet na geração do XML e podem ocorrer problemas utilizando a emissão em diversos lugares do Brasil.

Podemos verificar a alteração de alguns campos obrigatórios para DateTimeOffSet?

robertorp commented 7 years ago

Quais seriam os impactos? Uma coisa que quero mudar e, colocar parâmetros para algumas datas que são pegas automaticamente DateTime.Now quero retirar isso (logico deixar um default para não quebrar quem já utiliza), por causa dos emissores Web, isso ajudaria quem utiliza Web e deseja mandar a data do browser do cliente no lugar utilizar a data do servidor.

bruno-alencar commented 7 years ago

Um exemplo: Imagine emitir nota de todo lugar do Brasil. Existem diferentes tipos de Fusos Horários.

Se eu receber uma data com time zone -4h (exemplo Amazonas), ao virar DateTime, esse TimeZone é perdido e no momento da emissão utiliza-se o fuso da máquina.

Se o fuso da máquina estiver em UTC (0h) ou qualquer outra diferente, existe uma diferença grande do horário de emissão verdadeira, e o horário de emissão enviada.

Concordo contigo em usar um default caso não seja enviada, mas os horários ficam divergentes usando DateTime, trabalhando com diferentes fusos.

rftd commented 7 years ago

Na verdade o DateTime não da erro em emissão em vario lugares como o rapaz afirmar, ele da erro quando eu de um lugar tento emitir em outra uf que tenham o timezone diferente da minha. Agora na web este erro é sentido com mais força pois geralmente o fuso do servidor não esta como o da sua maquina. A ideia do DateTimeOffset é correta pois se vai usar varias timezones diferentes especificar as mesma usando o DateTimeOffset é o mais correto, na verdade é recomendado a usar sempre o DateTimeOffset em caso de desenvolvimento, eu pessoalmente não sei por que a M$ fez esta diferenciação.

robertorp commented 7 years ago

Vamos supor que você more em algum UF que tenha entrado no horário de verão, mas a sua UF autoriza num servidor que não tenha entrado no horário de verão. Bom no caso você estaria emitindo NF-e com dhEmi com uma hora a mais que o servidor seu, oque resultaria em rejeição.

Isso corrigiria isso? (Se não.. vou abrir uma issue para colocar um parâmetro opcional nas configurações para solucionar isso)

bruno-alencar commented 7 years ago

@rftd Correto, não da erro, mas altera o horário verdadeiro da emissão. Seja web, microservico ou qualquer emissão de lugares diferentes da máquina.

bruno-alencar commented 7 years ago

@robertorp O horário de verão é outro exemplo também, isso pode ocorrer mesmo.

Com DateTime e TimeZone diferentes, horários perto 00:00:00, pode alterar até mesmo o dia de emissão.

Na verdade, qualquer data que deveria ser DateTimeOffSet, ao se tornar DateTime pode acontecer isso nas conversões.

rftd commented 7 years ago

o certo é colocar DatetimeOffset apenas nos campos que necessitam da informação de timezone no resto não tem necessidade pois o mesmo será desconsiderado na hora de salvar no xml é so informa a data e hora correta que já resolve.

robertorp commented 7 years ago

Bom, vou colocar esta issue então como melhorias. @bruno-alencar Se for você mesmo que for fazer fique a vontade para fazer o pull. Agora se não for você, pode ser que demore um pouco mas uma hora fazemos.

Acho que e interessante levar em consideração oque o @rftd falou, somente nos campos que necessitam da informação de timezone

HClausing commented 2 years ago

Estava olhando a parte de datas do nfeProc e notei que todos os campos estão como DateTime.

Desta forma, usa-se o TimeZone da máquina para conversão do DateTime para DateTimeOffSet na geração do XML e podem ocorrer problemas utilizando a emissão em diversos lugares do Brasil.

Podemos verificar a alteração de alguns campos obrigatórios para DateTimeOffSet?

Pode assegurar que sim. Trabalho com software para escrituração Contábil e Fiscal, e isto aconteceu quando um cliente do Sudeste do País (GMT -3) importou arquivos XML's de fornecedores de outra Time Zone. O documento foi listado no Livro Fiscal de Entradas como escriturado no próximo dia do XML, uma vez que o emitente do documento fiscal preencheu apenas a Data, e não a hora (ficando 00:00:00).