Follow

7 characters in base32 (35 bits) is enough to count the milliseconds in a year.

So I could theoretically make a timestamp that looks like:

2019-2prafu0

That's pretty usable for autogenerated urls, don't you think?

(These fun facts brought to you by thinking about pleromas new flake id system and ideas seen on rustodon's issue tracker)

There might be a challenge regarding timezones and new years. It feels.. Wrong to force everyone to use UTC; most of the year it doesn't matter, but then suddenly your posts about breakfast in australia new years morning is marked as belonging to last year, because the british haven't entered the new year yet? If that isn't an artifact of imperialism, I don't know what is.

An alternative would be to just use two extra characters for 45 bit timestamps, and count milliseconds after unix epoch. That way it's not expected to change in lockstep with any human calendar.

But then it's just semi-unreadable garbage all of it :/

@kai that'll eat three characters just to get the date. This one gives me millisecond presicion with five characters.

@zatnosk oh, I didn't realize what it was. Cool!

@zatnosk oh hey I like that

The only potential issue is if you've got multiple machines or threads using the same system in which case you'll want at least one randomly generated character at the end to minimize potential conflicts

@zatnosk although... hrm I'm not sure what degree of time precision you need for expected loads

@InspectorCaracal yeah, but this is just the timestamp. Pleromas flake id's use 64bit timestamp + 48 bit worker id + 16 bit counter

I'm thinking add 5 characters with the rest of that, then you have 25 bits to share between workers ids and counter. I think that'll probably be enough for a small system (like a fediverse instance with <10k users.)

Sign in to participate in the conversation
Manowar.social

Private mastodon server run by Zatnosk