Date format error in documentation

[RaulPascual]

In the documentation of, for example, Team Radios, the date field is described as “2023-09-15T09:40:43:43.005000”
but in the API response, it is in another format “2023-09-15T09:40:43:43.005000+00:00”

The example URL to view it can be the same as the one in the documentation:
URL Example

In any case, great job on the overall project! 💯

[vitoramaral10]

o +00:00 é o timezone daquela hora, nesse exemplo está GMT caso o dado for de outro timezone ai estaria por exemplo -03:00 (Brasil), qual linguagem está utilizando? com isso posso te ajudar a fazer essas conversões de modo mais simples

[PrestonHager]

This is due to issue #32 if I remember correctly. The solution for handling dates within the database was to retain timezone information along with any date when processing the live-timing data. This shows on the front end of the API as the + with some timezone offset.

Either way, I think most standard datetime libraries handle timezone conversions. Would there be a use case for showing the dates without the timezone information? I don't think there's any harm in having +00:00 (UTC) as an offset.

Or is this issue addressing the differences in the documentation vs actual results?

[RaulPascual]

This is due to issue #32 if I remember correctly. The solution for handling dates within the database was to retain timezone information along with any date when processing the live-timing data. This shows on the front end of the API as the + with some timezone offset.

Either way, I think most standard datetime libraries handle timezone conversions. Would there be a use case for showing the dates without the timezone information? I don't think there's any harm in having +00:00 (UTC) as an offset.

Or is this issue addressing the differences in the documentation vs actual results?

Yes, there is no problem with the handling of dates, the issue is only to inform about the difference between the documentation and the actual results.