bacen / pix-api

API Pix: a API do Arranjo de Pagamentos Instantâneos Brasileiro, Pix, criado pelo Banco Central do Brasil.
https://bacen.github.io/pix-api
2.36k stars 268 forks source link

[Dúvida] Formato timestamp - RFC 3339 #163

Closed etanamati closed 3 years ago

etanamati commented 4 years ago

Gostariamos de tirar uma dúvida quanto ao formato dos campos do tipo timestamp (por exemplo, campos do payload QRCode dinâmico: calendario.criacao e calendario.apresentacao) que os PSPs devem considerar. De acordo com o manual de Padrões para iniciação do PIX versão 2.0 é definido que os campos do tipo timestamp devem respeitar o formato definido na RFC 3339. Seguem exemplos contidos na especificação: 1985-04-12T23:20:50.52Z 1996-12-19T16:39:57-08:00 1990-12-31T23:59:60Z 1990-12-31T15:59:60-08:00 1937-01-01T12:00:27.87+00:20

Ha alguma recomendação para uso, ou devemos considerar todas as variantes definidas na seção "5.6. Internet Date/Time Format" da especificação? O formato yyyy-MM-dd'T'HH:mm:ss (Exemplo: 2020-11-08T17:13:49) é um cenário válido?

rubenskuhl commented 4 years ago

Eu não recomendo deixar o fuso sem especificação; é meio caminho andado para problemas de interoperabilidade e rastreabilidade. Eu pessoalmente gosto de 1985-04-12T23:20:50.52Z e 1990-12-31T23:59:60Z.

randrade86 commented 4 years ago

Eu também recomendo utilizar fuso horário.

Inclusive, alguns PSPs que tivemos contato estão colocando o horário corrente (no fuso de brasília) e simplesmente concatenando um "Z", sem saber que representa GMT-0, resultado: qualquer QRCode com expiração < 3 horas "nasce" expirado.

ninrod commented 4 years ago

O formato yyyy-MM-dd'T'HH:mm:ss (Exemplo: 2020-11-08T17:13:49) é um cenário válido?

Vamos seguir a RFC e vamos manter o Z para cravar GMT-0.

1985-04-12T23:20:50.52Z e 1990-12-31T23:59:60Z seriam exemplos aderentes.

thiagolvlsantos commented 3 years ago

Dúvida aparentemente esclarecida.

Atenciosamente, Thiago Santos.