aevitas/flakeid

Specific Timestamp Support

Closed this issue · 2 comments

In championing an upgrade for the FlakeId package, this proposal emphasizes the integration of bespoke timestamps into the Snowflake ID generation process.

The current methodology confines Snowflake ID generation solely to the current timestamp, prompting a call for sophistication. This enhancement introduces a layer of flexibility by enabling users to precisely define a timestamp, thereby amplifying the overall adaptability of the FlakeId package.

The suggested approach involves enhancing the existing Create method to gracefully accept an optional timestamp parameter, promoting consistency and simplicity in the API. This enhancement is inspired by the theoretical foundation for generating Snowflake IDs from a timestamp, as exemplified by (timestamp_ms - EPOCH) << 22 which originates from the Discord API documentation.

This proposed enhancement seeks to provide users with unparalleled control over timestamp association, aligning Snowflake ID generation precisely with their application's needs.

To incorporate this enhanced functionality, users would apply the following approach:

long id = Id.Create(timestamp);

This example showcases the simplicity and versatility that the proposed enhancement brings to Snowflake ID generation within the FlakeId package.

In conclusion, the integration of bespoke timestamps represents a significant stride towards a more sophisticated and adaptable ID generation process.

Hi Dennis,

In your use case, are you looking to migrate a bunch of data that uses non-flake IDs to Snowflakes? If so, do you have timestamps available from said original data (e.g. in a SQL column), or are you looking to pass arbitrary values as the timestamp?

Implementing this shouldn't be an issue, the current Create() call simply retrieves the timestamp from the monotonic timer. Adding an overload that accepts a timeStampMs argument or similar and uses that instead of the monotonic timestamp and updating the CreateInternal method accordingly I think is all that needs to be done.

@aevitas That is precisely the use case upon which I have based my proposal.