To give a serious answer, when a post is made it's the client's responsibility to provide the timestamp. If you wanted to you could provide an inaccurate one
It's not quite *that* bad, the spec says it ought to be the intersection of ISO8601, RFC3339, and WHATWG HTML. Cursed AF but less cursed than most other options tbh. (I haven't checked if it's actually implemented that way though.)
The thing we need to allow for is someone importing their entire post history to a new server. You obviously need backdating in that case. We separately track index date, and i think thats also exposed to the client.
rkeys are (currently) never used for displayed timestamps btw, if you see a more recent timestamp it's because it's taking "indexedAt" rather than "createdAt"
fwiw, your post record still says 2010 (createdAt), but the API is currently returning the correct indexedAt date (as opposed to mine, which misleadingly returns the createdAt in place of indexedAt)
So there's nothing I can do then? It was hard to even make that post, I had to set my computers date and then quickly post before my browser started refusing connection. If that no longer works I'm screwed (also my phone only goes back to 2015)
Which aspect though? I've done several types of recursive post and they didn't recur indefinitely in api responses last time I checked (the appview has mechanisms that are supposed to prevent it)
These display differently from my last check. I don't remember too many of the specifics of how I did most things; I got a bit silly with it.
I sort of stopped bothering when my security@ email was ignored (except to say they fixed docs). I'm pretty sure there are as-yet-unreported vulnerabilities.
Weird, must be drawing from region in my system settings (iOS) as my date format is set to the Correct Date Format (yyyy-mm-dd) and I don't see an app setting for this. (I'm on US region because I need some US apps and Wirld Iz Harrd apparently.)
Comments
ALSO NO, IT WAS NOT A LOVELY DAY !
IT WAS SUPER HOT , TRAFFIC WAS BAD AND THE MEDIA COMPLAINED ABOUT A UNUSUAL SILENCE IN THE AIR.
but I been wrong before
https://cdn.standards.iteh.ai/samples/70907/5e8d00e639cf4f849462bd63062f4cd8/ISO-8601-1-2019.pdf
Such a strange decision
https://bsky.app/profile/did:plc:f3vzol6kqt2zps3zgcssfhhl/post/0 -- 1969.
I sort of stopped bothering when my security@ email was ignored (except to say they fixed docs). I'm pretty sure there are as-yet-unreported vulnerabilities.
May or may not be related?
I need to know!