Dúvida sobre data de vencimento e data de criação

[wesleygonalv]

Se eu criar uma cobrança as 22h no horário de Brasília do dia 28/07 a data de criação da cobrança no padrão UTC-0 vai informar data do dia 29/07, correto?

O que acontece se eu colocar uma data de vencimento para o mesmo dia? cadastrando assim uma cobrança ás 22h, o resultado do calendário deve ficar assim?

dataDeCriacao = "2021-07-29T01:00:00.000Z" dataDeVencimento = "2021-07-28"

[wesleygonalv]

E se eu consultar a mesma cobrança ás 23h ainda no dia 28/07 pelo GET ​/cobv​/{pixUrlAccessToken}, ela vai está vencida?

[wesleygonalv]

Em resumo, na consulta a data de referência para validar se a cobrança está vencida ou não deve ser em horário de Brasília ou UTC?

[wesleygonalv]

E o que deve acontecer com diferentes fusos? deve ser considerado o codMun?

[rubenskuhl]

Que eu lembre as respostas da API vão ser sempre UTC, mas que os PSPs devem aceitar toda codificação que a RFC 3339 identifique como válida, convertendo internamente o fuso. E sim, o codMun impacta a definição de fuso no cobv (mas não no cob).

[ninrod]

@wesleygonalv, meu entendimento é que o horário em UTC deve ser adaptado para o timezone do usuário pagador pelo app cliente. Então, em um mesmo momento na linha do tempo, uma cobrança pode estar válida em Brasília e vencida em Sidney. Parece fazer sentido essa forma de operar, porque eventuais diferenças de timezone seriam resovidas na ponta enquanto os timestamps ficam todos cravados em UTC no núcleo.

Recomendo confirmar essa interpretação com o DECEM.

[wesleygonalv]

@wesleygonalv, meu entendimento é que o horário em UTC deve ser adaptado para o timezone do usuário pagador pelo app cliente. Então, em um mesmo momento na linha do tempo, uma cobrança pode estar válida em Brasília e vencida em Sidney. Parece fazer sentido essa forma de operar, porque eventuais diferenças de timezone seriam resovidas na ponta enquanto os timestamps ficam todos cravados em UTC no núcleo.

Recomendo confirmar essa interpretação com o DECEM.

Entendo que o ciclo de vida da cobrança seria assim, correto?

O CLIENTE CRIOU UM COBV ÁS 28-07-2021T22:00:00-03:00 UTC-3

O SERVIÇO DEVE CADASTRAR ÁS  29-07-2021T01:00:00Z                                UTC0
O CLIENTE INFORMOU O VENCIMENTO = 28-07-2021                                     UTC-3
O SERVIÇO CADASTRA O VENCIMENTO = 29-07-2021                                     UTC0

O CLIENTE CONSULTA ÁS 28-07-2021T22:30:00-03:00 UTC-3

O SERVIÇO RETORNA DATA DE CRIAÇÃO ------------------------------------> 29-07-2021T01:00:00Z            UTC0
O SERVIÇO RETORNA DATA DE APRESENTAÇÃO -------------------------------> 29-07-2021T01:30:00Z            UTC0
O SERVIÇO RETORNA A DATA DE VENCIMENTO -------------------------------> 29-07-2021                  UTC0

O APLICATIVO DO CLIENTE EXIBE DATA DE CRIAÇÃO ------------------------> 28-07-2021T22:00:00-03:00       UTC-3
O APLICATIVO DO CLIENTE EXIBE  DATA DE APRESENTAÇÃO ------------------> 28-07-2021T22:30:00-03:00       UTC-3
O APLICATIVO DO CLIENTE DEVE EXIBIR O VENCIMENTO ---------------------> 28-07-2021                      UTC-3

Observações:

• O serviço seria a api pix;
• O cliente está em São Paulo;

[rubenskuhl]

Eu acho que já foi citado o fuso do domicílio bancário do cliente (de onde ele é segundo o KYC), e não aonde o cliente está no momento (que pode ser em Tokyo participando como atleta olímpico, por exemplo).

[ninrod]

@wesleygonalv ,

acredito que a construção do seu exemplo está errada nestas duas linhas:

O CLIENTE INFORMOU O VENCIMENTO = 28-07-2021 UTC-3 O SERVIÇO CADASTRA O VENCIMENTO = 29-07-2021 UTC0

O vencimento não é convertido para UTC porque não há informação de horas, apenas dias.

[wesleygonalv]

@wesleygonalv ,

acredito que a construção do seu exemplo está errada nestas duas linhas:

O CLIENTE INFORMOU O VENCIMENTO = 28-07-2021 UTC-3 O SERVIÇO CADASTRA O VENCIMENTO = 29-07-2021 UTC0

O vencimento não é convertido para UTC porque não há informação de horas, apenas dias.

@ninrod ok entendido.

Logo se eu criar uma cobrança ás 21h do dia 28-07-2021, não posso atribuir uma data de vencimento para o mesmo dia, pois a data de criação respeita a UTC0?

Nesse cenário é retornado a mensagem:

O campo cobv.calendario.dataDeVencimento é anterior à data de criação da cobrança.

[wesleygonalv]

Eu acho que já foi citado o fuso do domicílio bancário do cliente (de onde ele é segundo o KYC), e não aonde o cliente está no momento (que pode ser em Tokyo participando como atleta olímpico, por exemplo).

@rubenskuhl independe do fuso realmente, o que estou querendo levantar é que uma cobrança com vencimento consultada após as 21h no horário de Brasília será aplicado juros e multa pois na consulta da data e hora para saber se a cobrança está vencida será retornada em UTC.

Ah Wesley, mas como @ninrod falou:

O vencimento não é convertido para UTC por que não há informações de horas, apenas dias.

Super válido, mas se você consultar a data dentro do serviço que está sempre funcionando em UTC, ás 21h do dia 28/07 no fuso de Brasília o serviço vai lhe retornar no dia 29/07.

Se for para verificar se a cobrança está vencida ou não, eu estou entendendo que devemos sempre validar a data de vencimento com o fuso de Brasília e não mais UTC0.

[renatofrota]

@wesleygonalv ,

Se eu criar uma cobrança as 22h no horário de Brasília do dia 28/07 a data de criação da cobrança no padrão UTC-0 vai informar data do dia 29/07, correto?

Sim, uma cobrança criada às 22:00 de 28/07 (no horário de Brasília, UTC -3), terá a data de criação 29/07 01:00 (UTC).

O que acontece se eu colocar uma data de vencimento para o mesmo dia? cadastrando assim uma cobrança ás 22h, o resultado do calendário deve ficar assim?

dataDeCriacao = "2021-07-29T01:00:00.000Z" dataDeVencimento = "2021-07-28"

Sim.

Logo se eu criar uma cobrança ás 21h do dia 28-07-2021, não posso atribuir uma data de vencimento para o mesmo dia, pois a data de criação respeita a UTC0?

Nesse cenário é retornado a mensagem:

O campo cobv.calendario.dataDeVencimento é anterior à data de criação da cobrança.

Teoricamente você poderia criar, sim. A documentação não é taxativa mas me parece ser um erro do PSP. Ele deveria levar em consideração que há, oficialmente, fusos até UTC -12. Ou, pelo menos, considerar que há, no Brasil, fusos até UTC -5, e permitir a criação de cobranças para uma data que, olhando do ponto de vista do horário da criação da cobrança em fuso UTC, a data (dia/mes/ano) parece estar "vencido há 1 dia", mas na realidade ainda é no mesmo dia da criação da cobrança para o criador da mesma (e seria, consequentemente, potencialmente pagável). Você está observando esse erro em algum PSP?

independe do fuso realmente, o que estou querendo levantar é que uma cobrança com vencimento consultada após as 21h no horário de Brasília será aplicado juros e multa pois na consulta da data e hora para saber se a cobrança está vencida será retornada em UTC.

Nesse ponto, você está errado. O fuso horário de quem está consultando a cobrança deve ser levado em conta. Se o vencimento da cobrança é 30/08 e ele consulta a cobrança 30/08 às 23:59 ela ainda deve ser considerada pagável, não vencida e não ter acréscimo de multa/juros.

Se for para verificar se a cobrança está vencida ou não, eu estou entendendo que devemos sempre validar a data de vencimento com o fuso de Brasília e não mais UTC0.

Em nenhum momento você deve considerar o fuso de Brasília como absoluto. O fuso do pagador é que importa. Se ele for do Acre, o fuso dele é -5 e não -3, por exemplo.

[wesleygonalv]

Em nenhum momento você deve considerar o fuso de Brasília como absoluto. O fuso do pagador é que importa. Se ele for do Acre, o fuso dele é -5 e não -3, por exemplo.

Opa @renatofrota, entendi o ponto, e isso o banco teria que levar em consideração o codMun, correto?

[renatofrota]

Em nenhum momento você deve considerar o fuso de Brasília como absoluto. O fuso do pagador é que importa. Se ele for do Acre, o fuso dele é -5 e não -3, por exemplo.

Opa @renatofrota, entendi o ponto, e isso o banco teria que levar em consideração o codMun, correto?

Correto, a partir do codMun identifica-se a situação da cobrança (em dia ou vencida) e realiza-se os cálculos de multa/juros pertinentes, se for o caso.

[wesleygonalv]

@ninrod seria isso ?

[rubenskuhl]

Em nenhum momento você deve considerar o fuso de Brasília como absoluto. O fuso do pagador é que importa. Se ele for do Acre, o fuso dele é -5 e não -3, por exemplo.

Opa @renatofrota, entendi o ponto, e isso o banco teria que levar em consideração o codMun, correto?

Sim, o codMun. Mas um caso a tratar é quando todas as requisições daquele payload do cobV vieram sem codMun... aí você tem que arbitrar um fuso, e o que faz mais sentido é de fato a hora oficial brasileira, na falta de melhor de informação. Quer seja por ser a hora oficial ou por que a maior parte da população do país está localizada em estados que seguem o mesmo fuso.

[rubenskuhl]

Eu acho que já foi citado o fuso do domicílio bancário do cliente (de onde ele é segundo o KYC), e não aonde o cliente está no momento (que pode ser em Tokyo participando como atleta olímpico, por exemplo).

@rubenskuhl independe do fuso realmente, o que estou querendo levantar é que uma cobrança com vencimento consultada após as 21h no horário de Brasília será aplicado juros e multa pois na consulta da data e hora para saber se a cobrança está vencida será retornada em UTC.

Ah Wesley, mas como @ninrod falou:

O vencimento não é convertido para UTC por que não há informações de horas, apenas dias.

Super válido, mas se você consultar a data dentro do serviço que está sempre funcionando em UTC, ás 21h do dia 28/07 no fuso de Brasília o serviço vai lhe retornar no dia 29/07.

Mas não seria vencida porque não há nenhum domicílio bancário no Brasil cujo fuso seja UTC.

Se for para verificar se a cobrança está vencida ou não, eu estou entendendo que devemos sempre validar a data de vencimento com o fuso de Brasília e não mais UTC0.

Com o fuso do domicílio bancário do pagador, não com o de Brasília. As 23h do dia 28.08 essa cobrança só estará vencida em Fernando de Noronha (se é que eles ainda usam UTC -2 por lá).

[ninrod]

Pessoal, muito pertinentes as observações de vocês @renatofrota, @wesleygonalv e @rubenskuhl.

Também acredito que o fuso a ser considerado é o fuso relacionado ao codMun (domicílio bancário do usuário pagador) até porque é essa a informação que o PSP recebedor conhece (se atribuída como parâmetro do GET da location).

Por outro lado, alguém poderia defender que o fuso a ser considerado seria o fuso real do usuário pagador. Como já dito aqui, o usuário pagador poderia estar no japão para as olimpíadas e querer pagar uma cobrança Pix. Entendo que essa interpretação parece ser mais benéfica ao usuário pagador do que simplesmente considerar o codMun. Nesse caso, teríamos que especificar como o PSP recebedor se comportaria frente a essa possibilidade, já que ele não tem acesso ao fuso local do usuário pagador.

Baseados nesses pontos, acredito que vale uma consulta formal ao DECEM vix pix@bcb.gov.br referenciando esta issue.