I've encountered what might be the worst date/time format I've see thus far.
"11-10T08:08:02.000Z"
That's right, it's ISO-8601 except without the year. I thought this was a bug on my end, then in the XML parser, then in their API, until I found that it is in fact supposed to be like this.
The worst part about this is someone had to go through *extra* work to remove the year and make this value significantly more difficult to work with.
mroach /
npub1jm…5vwex
2023-11-14 12:02:49
Author Public Key
npub1jm640dm2se8v7rp9d4d9tuuwr7le59d37lgucxfvpurct84yaxgqr5vwexPublished at
2023-11-14 12:02:49Event JSON
{
"id": "2dd6a5a82f1189259079b723080e5da18c7ce1c26316ac53ec01960e4a97cd2b",
"pubkey": "96f557b76a864ecf0c256d5a55f38e1fbf9a15b1f7d1cc192c0f07859ea4e990",
"created_at": 1699963369,
"kind": 1,
"tags": [
[
"proxy",
"https://mas.to/users/mroach/statuses/111408799402875106",
"activitypub"
]
],
"content": "I've encountered what might be the worst date/time format I've see thus far. \n\n\"11-10T08:08:02.000Z\"\n\nThat's right, it's ISO-8601 except without the year. I thought this was a bug on my end, then in the XML parser, then in their API, until I found that it is in fact supposed to be like this.\n\nThe worst part about this is someone had to go through *extra* work to remove the year and make this value significantly more difficult to work with.",
"sig": "66c2a2cf5df2640ebc63d4d4b29a47d256ffe2407ae1f6f56a85d1a457c0e362b1df4bf67672feb6fd9f9aba5140ac91af9447982be84f6d3e1899888e77ef9b"
}