How to extract time from an uuid v1?

[aalexgabi]

I found this: krassif@a9aac0e
From here: https://stackoverflow.com/questions/17571100/how-to-extract-timestamp-from-uuid-v1-timeuuid-using-javascript

But since node-uuid (the npm module) is deprecated: https://www.npmjs.com/package/node-uuid what can I use?

It looks to me that this feature should be included in this library.

[broofa]

https://www.npmjs.com/package/uuid-time works. Just be aware that the value it returns (Unix epoch, +/- 1 msec) is imprecise. (v1 uuids are precise to +/- 0.01 μsec)

See also #49 (comment)

[aalexgabi]

Thanks!

[croraf]

Can this be included in this library? (would offer TS support also)

[ctavan]

Given there has not been a single request for this feature in the past 3 years and given there’s a dedicated npm module for this use case, I think it’s very unlikely that we‘ll support this feature in this library.

[broofa]

~10-15 people have shown interest in this feature in the last decade (including comments on #49). The uuid-time module that spun out of that gets ~900 downloads/week, compared to uuid's current traffic of 67M/week.

In addition to the lack of demand, there's also the matter of deciding what the "right" API should be. I'm not convinced there's good solution here, due to the [arguably] poor choice of epoch used in RFC4122 (gregorian epoch, 100-nsec units) that makes using JS Number objects for timestamps problematic. uuid-time returns a JS timestamp value (unix epoch, msec units), but drops out of necessity drops the sub-msec info. uuid uses msec and nsec values internally and (regrettably?) exposes those in the API. But those are ad-hoc and pretty arbitrary in how they're defined. Really, the best datatype for is probably BigInt, but BigInts are cumbersome to work with. (E.g. new Date(1234n) throws) and, I suspect, probably aren't what most people need.

Oh, and there's a new proposal in the works - https://github.com/uuid6/uuid6-ietf-draft - that adds another epoch to the mix. (Unix, 1-nanosecond units).

I guess the TL;DR: is that I [still] don't see a solution popular and "right" enough to warrant taking this.