fix - ignore milliseconds on dates since the API can't decide on a format

[mormaer]

Checklist

• I have read CONTRIBUTING.md
• I have described what this PR contains
• This PR addresses one or more open issues that were assigned to me:
  - No issue, but it's a problem that's been around since the start...
• If this PR alters the UI, I have attached pictures/videos

Pull Request Information

About this Pull Request

- This PR is going to drop our date precision by ignoring the millisecond value that is
- inconsistently returned by the API. I'm not a fan of this, but it appears we have
- a decision to make between failing to model our response (user sees nothing)
- or risking two posts/comments/actions that happened at _almost_ the same time
- being placed slightly out of sequence. The latter here feels like the lesser evil.

This PR adjusts how we attempt to decode dates returned from the Lemmy instances.

We have seen many different formats returned by the API. Looking into the Lemmy source they are using Timestamptz which is described as;

The “timestamp with time zone” SQL type, which PostgreSQL abbreviates to timestamptz.

It would appear that we should be able to expect dates in the format yyyy-MM-dd'T'HH:mm:ss.SSSSSSZ, however this is not the case, and a sample taken from a live instance earlier gave values with and without milliseconds:

2023-09-14T13:01:51.477605Z"
2023-09-14T11:04:10Z"
2023-06-11T03:13:06Z"
2022-01-28T13:31:12.294106Z"
2023-08-31T01:51:20.227750Z"
2023-09-14T11:04:10Z"
2023-09-14T12:10:48.605934Z"

These values are all from `.post` objects, but the same inconsistent behaviours can be observed
on other objects throughout the API.

The existing set of formats we have suggest that we've also been seeing dates with 4 digit millisecond precision and with/without the separating T between the date and time, however I've not seen those on any instance I've tested on.

I have seen issues frequently when switching between accounts quickly, where responses will fail to parse (failing on dates) but refreshing will often resolve it. Even though the data itself has not changed 🤯 this suggests the current approach of using a single formatter and adjusting its .dateFormat on the fly during decoding may also be introducing problems.

This new approach has two separate formatters, one using yyyy-MM-dd'T'HH:mm:ss, and a second using yyyy-MM-dd HH:mm:ss. The logic has been updated to attempt to match the returned date string from the API using regex to extract the date minus the millisecond portion for the first format, and parse it... if that fails, it attempts to match the second format and parse that.

In testing (across three instances) it is always the first format we encounter and so the second formatter here may be redundant.

@ShadowJonathan, I would appreciate your input on this PR if you're free. I have a vague memory from many months ago when we discussed date formats from Lemmy and we did think there may be two formats, was it with and without the T separator that you reckoned may appear? If so leaving the second redundant formatter would make sense to ensure we're covered in that scenario.

Given the variations we're seeing appear to always be in the millisecond portion of the string I believe this will resolve the failures we're seeing. I can no longer re-create the failures I was seeing when switching quickly between multiple accounts.

Screenshots and Videos

No changes to the UI.

[mormaer]

Closing as this was solved by #603