stop internally representing timestamps as strings

timestamps were never supposed to be readable by both humans and machines simultaneously

@retr0id
"Hello I didn't mean 18:20:00+00:00 I specifically meant 18:20:00Z and I want the Z preserved"

statements dreamt up by the utterly deranged

@wolf480pl lol - is there any world in which they're not semantically equivalent?

@retr0id idk but my point is, a string representation preserves useless syntactical information that doesn't affect the meaning of the timestamp, and leaves more room for invalid values or parser confusion due to differing implementation details.
Who'd want any of that?

@wolf480pl For some fun extra context, timestamps are on my mind because I recently broke large portions of the Bluesky ecosystem with the timestamp "0000-01-01T00:00:00+14:00"

@retr0id and storing that as a pair of int64_t (ts, zone) and serializing to a normalized isoformat for interchange would've avoided that problem? Interesting....

@wolf480pl noooo! timezone is not relevant information! it should not be stored here! Any integer serialisation of UTC (or maybe even TAI if you're feeling adventurous) would solve this

@wolf480pl and if you *really* want to encode the timezone of a poster for some reason, that should be like, an entirely separate informational field

@retr0id TZ matters for recurring events

@wolf480pl example?

@wolf480pl oh I can kinda see the usecase there, if a human has said "do this task at 6pm evey day" a la crontab

@retr0id @wolf480pl some collaboration tools do stuff like "x sent y at 1pm (5pm their time)", which is somewhat useful.