Title
#dev
Ariel Shaqed (Scolnicov)

Ariel Shaqed (Scolnicov)

09/06/2022, 10:40 AM
Does anyone know of an ASCII representation for timestamps, similar to ISO8601, but that sorts in reverse order? Long form: @Yoni Augarten and I are working on improving usability of run_id in GC. Currently in order to discover which run_id to provide to a run, you pretty much need a KV store to keep the last few run_ids by time. That's an ops problem. As a first step we want to change the format of run_ids to be sort -- so instead of
<UUID>
we will use something like
<TS_ISO_8601>-<RANDOM>
. Now the files
.../retention/gc/commits/run_id.../commits.csv
will list in time-sorted order. So no need for KV, we can simply list these objects in S3. Unfortunately, it is still hard to go backwards in such a list. And that's actually the preferred mode: "find the last run_id from at least 2 weeks ago". So... I'd really like to name them
<REVERSE_8601_ISH>-<TS_ISO_8601>-<RANDOM
, where RANDOM_8601_ISH is an ISO 8601-like printable representation of timestamp that sorts in reverse order, and we include TS_ISO_8601 merely for readability. Now we just need an encoding 🙂 Where I've gotten so far: use a 9s-complement ASCII representation. An even less-readable representation would use e.g.
10000000000 - EPOCH
(right now would be
8337539453
(== 10000000000-1662460547), and 5 seconds later it would be
8337539448
. A more-readable representation might use
<10000-YYYY>-<100-mm>-<100-DD>N<100-HH>:<100-MM>:<100-SS>
, and let you decode in your head with a little effort. Is there any more standard way to do this?
10:41 AM
(Apart from RFC 2550 - Y10K and Beyond, of course.)
11:09 AM
Amusingly, the above 2 suggestions are precisely this answer and the one below it (StackOverflow).
1:33 PM
When we switched from db implementation to kv implementation we make something like the above, while converting the current time based to the reverse order key.
1:52 PM
The code we use today to generate new IDs for actions