Closed etanamati closed 3 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.
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.
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.
Dúvida aparentemente esclarecida.
Atenciosamente, Thiago Santos.
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?