Timestamp::from_unix - Why is the `seconds` parameter a u64 and not i64?

[ragnese]

What happened?
Nothing happened. Just a question about the API.

What were you expecting?
Since unix timestamps are the number of seconds since 1970, one might expect that a negative value is valid. This is true of popular date-time crates such as "time" and "chrono"; they both treat unix timestamps as i64.

What's the context?

• Version 0.8.x

[Ashley Mannix]

Hi @ragnese 👋

This is probably just aligned with libc's timespec structure, which I think uses an unsigned field. The timestamp in a v1 UUID is also really more of a counter that doesn't have any need to be initialized with a negative value, so you can rest easy knowing our unsigned UUIDs give you another ~300 billion years of valid representation over the signed alternative 🙂

[ragnese]

Thanks for the reply.

This is a very trivial issue, so please don't take this as me being difficult. I'll sleep just as well if it stays the way it is. :)

This is probably just aligned with libc's timespec structure, which I think uses an unsigned field.

For what it's worth, the C standards allow for signed values: https://www.gnu.org/software/libc/manual/html_node/Time-Types.html
And the Rust libc also uses i64: https://docs.rs/libc/latest/libc/struct.timespec.html

I do understand that it doesn't actually matter for generating a UUID, but the real reason I feel like it's worth changing this function's signature (even if you just do a wrap-around conversion or something inside it) is just for convenient use of the API. Every Rust date-time type from any crate I'm aware of, uses an i64 for a Unix timestamp. So I'm fairly sure that everyone who uses this function is either manually converting from some kind of datetime::now().to_unix_timestamp() or just "cheating" and using some const/literal because it doesn't matter.