feat: Add Tid::now and Tid::from_datetime constructors
#277
Conversation
| fn s32_encode(mut i: u64) -> String { | ||
| const S32_CHAR: &[u8] = b"234567abcdefghijklmnopqrstuvwxyz"; | ||
|
|
||
| let mut s = String::new(); |
There was a problem hiding this comment.
nits: this should be String::with_capacity(13)
| } | ||
|
|
||
| // Reverse the string to convert it to big-endian format. | ||
| s.as_str().chars().rev().collect() |
There was a problem hiding this comment.
nits: .as_str() may be unnecessary
| /// | ||
| /// Clock IDs 0-31 can be used as an ad-hoc clock ID if you are not concerned | ||
| /// with this parameter. | ||
| pub fn from_datetime(cid: u32, time: chrono::DateTime<chrono::Utc>) -> Self { |
There was a problem hiding this comment.
The parameter name cid is easily confused with the Cid of ipld_core, so I think we should use the name clock_identifier or clock_id instead of omitting it here.
There was a problem hiding this comment.
Good call! Yeah I was thinking about clkid before submitting this. Will change it to one of the above :)
| /// | ||
| /// Clock IDs 0-31 can be used as an ad-hoc clock ID if you are not concerned | ||
| /// with this parameter. | ||
| pub fn from_datetime(cid: u32, time: chrono::DateTime<chrono::Utc>) -> Self { |
There was a problem hiding this comment.
And what would be the appropriate type for the clock identifier?
This value is only used for the lower 10 bits, and atrium_api::types::integer defines a type that takes into account various bounds. I think LimitedU32<1023> would be appropriate here, what do you think?
| @@ -436,6 +452,27 @@ impl Tid { | |||
| } | |||
| } | |||
|
|
|||
| /// Construct a new timestamp with the specified clock ID. | |||
| /// | |||
| /// Clock IDs 0-31 can be used as an ad-hoc clock ID if you are not concerned | |||
There was a problem hiding this comment.
Is the Clock ID 0-31? I am wondering because the specs say 10bit and it seems to be a value in the range 0-1023. If you know, I would like to know.
There was a problem hiding this comment.
Here's some more info that I've found online: bluesky-social/atproto#1160 (comment)
It appears that the clock ID partitioning did not make it into the specification - but based on this, clocks 0-31 are ad-hoc identifiers (and one is randomly chosen by the reference implementation).
There was a problem hiding this comment.
Thanks for the reply! I don't think we need to bother writing about the 0-31 range as long as it is not explicitly stated in the specification.
It seems more important to have a mechanism to ensure that a value larger than the previously issued timestamp is generated in order to avoid collisions.
|
@sugyan Btw sorry - I've been pretty spotty just because I'm limited on time here; I'm doing this work in my free time at this point. If you want to speed this along, absolutely feel free to push changes to my branch here. If not, I will follow-up eventually :) |
This simply adds some new
Tidconvenience constructors so that users do not have to write their own if they want to construct a timestamp.