Date inconsistencies in the API

[algernon]

The created and updated properties of posts appear as RFC3339 formatted strings in API responses, but they must appear as %F %T (ie, %Y-%m-%d %H:%M:%S, without any timezone specifier) when sending them back to the API. I think both responses & inputs should use the same format (probably RFC3339, which is what the documentation says).

As a followup to this, I discovered another inconsistency with dates, this one is considerably trickier to workaround: when I create a new post (either via /api/collections/{alias}/posts, or /api/posts), the created property (and likely updated too, I haven't verified that yet) is ignored unless it is in RFC3339 format. Other parts of the API expect the format in %F %T, and error out if the format isn't that. These two endpoints ignore the property if it fails to deserialize.

Reproduction:

❯ curl -s "http://localhost:9081/api/posts" \
    -H "content-type: application/json" \
    -H "Authorization: Token ${TOKEN}" \
    -X POST -d '{"body":"test", "created":"2023-11-10 12:00:00"}' \
    | jq -r .data.created
2023-11-09T00:07:24Z

Notice that the date I set is different from the one returned after post creation. Changing the date format results in the correct created date:

❯ curl -s "http://localhost:9081/api/posts" \
    -H "content-type: application/json" \
    -H "Authorization: Token ${TOKEN}" \
    -X POST -d '{"body":"test", "created":"2023-11-10T12:00:00Z"}' \
    | jq -r .data.created
2023-11-10T12:00:00Z

However, trying to update a post with RFC3339 format date fails:

❯ curl -s "http://localhost:9081/api/posts/82rxw75xdc" \
    -H "content-type: application/json" \
    -H "Authorization: Token ${TOKEN}" \
    -X POST -d '{"body":"test", "created":"2023-11-10T12:00:00Z"}'
{"code":500,"error_msg":"This is an unhelpful error message for a miscellaneous internal error."}

In the logs, I see:

ERROR: 2023/11/09 01:14:43 database.go:792: Unable to parse Created date: parsing time "2023-11-10T12:00:00Z" as "2006-01-02 15:04:05": cannot parse "T12:00:00Z" as " "

I can work this around in my client library by sending an update request immediately after a create, if the request had a created or updated property. But that's... not very nice. Serializing one way for one endpoint, and another way for the other would be even uglier.