API: "created" does not return ISO 8601 in microseconds

[Knight1]

The API @ v1/domains/ returns

[
  {
    "created": "2020-04-30T23:21:10Z",
    "published": "2020-04-30T23:21:14.513960Z",
    "name": "MyHumbleDomain.tld",
    "minimum_ttl": 3600
  }
]

docs says that "created" should be ISO 8601 with nanoseconds but it is not, only "published" is. I tried to find the code but I think it is more deep than I thought. https://github.com/desec-io/desec-stack/blob/46216fda804d3c15371393ec44d417a5935970d5/docs/dns/domains.rst#L20

[peterthomassen]

In ISO 8601, the second fraction part is optional, so the returned date is still in ISO 8601 format.

However, you are right that the second fraction was missing throughout because the database column type was set too narrow. This must have been due to some Django migration back in the days which didn't cover this aspect properly. The code is actually such that new deployments have the right column type.

We changed the column type in our production environment so that second fractions are now recorded for new domains. For existing domains, a second fraction of .000000 has been appended in the database. It seems that the the Django REST Framework DateTimeField serializer omits trailing zeros (although this is undocumented*), which is why the display for existing domains is unchanged.

@nils-wisiol Do you think this deserves a fix?

*edit: The fact that a zero second fraction is omitted is due to the behavior of Python's datetime.isoformat():

Return a string representing the date and time in ISO 8601 format:

• YYYY-MM-DDTHH:MM:SS.ffffff, if microsecond is not 0
• YYYY-MM-DDTHH:MM:SS, if microsecond is 0

[nils-wisiol]

In the example you are referring to, .000000 is explicitly printed. So if anything, the DRF docs would be misleading. While I don't think it's super-important for us, I think this should eventually be fixed, and maybe DRF appreciates a fix, too.