Admittedly that's probably a rare problem, but I can imagine it could have broken something

(An interesting tidbit: Since 2018-07-22, a 32-bit signed time_t with an epoch of 1970-01-01 has been able to represent the date of birth of every living human. Chiyo Miyako was born 1901-05-02 and died 2018-07-22 at the age of 117 years, 81 days. 2^31-1 seconds before the epoch was 1901-12-13. Reference: https://en.wikipedia.org/wiki/List_of_the_verified_oldest_pe...)

It's certainty one way to do it, but I'm pretty sure this is unacceptable to most kernels.

But this blog post is about how code which is already using 64 bit ints can have code which silently truncates. Another case of C's loose handling of types, whereas in Rust there would've been an explicit cast required (granted, in this case the macro expands to having explicit type casts)

    current_unix_time+1 second > current_unix_time

Imagine a C style packed bitfield structure similar to this:

  struct t_timebf {
    uint8 timesystem : 8;
    sint64 timedata : 56;
  }

Up to 255 standards may be defined which will define at least: an epoch for that standard, how the 56 bits for the timedata field are used to store data.

Standard 255 should be reserved as invalid (a guard against timestamp manipulation error).

Standards 254 down through 248 should be reserved in case there is a need for a program specific format that should not be handled by a standard library. The seven slots are reserved to allow up to that many revisions / variations of new timestamp types without further complicating the software.

Standard 0 might be reserved or assigned to Unix epoch timestamps. (see also 255 for folding naive manipulations back to a 56 bit timestamp.)

Standard 1 might be 56-bit microseconds (0.001 seconds), with a Unix epoch?

Standard 2 might be 56-bit milliseconds (0.000001 seconds), with a Unix epoch?

Standard 3 might be 56-bit nanoseconds (0.000000001 seconds), with a Unix epoch?

Those are (approximately) the current popular ranges of timestamps, and the reason for supporting 1e+0, 1e-3, 13-6, and 1e-9 are the approximately 30, 20, 10, and 0 extra bits of offered precision over the other timestamps.

When writing that out however, I realized that even at a full 64 bits, a nanosecond precision timestamp has a woefully inadequate number of bits. (only ~524 years of precision according to someone that did the math ( https://stackoverflow.com/questions/43451565/store-timestamp... ))

If storage isn't a concern, it might be better to utilize 128 or more bits for a timestamp to ensure there's sufficient room for the desired range. However at that point it makes much more sense for application specific choices.

A timestamp in many applications should probably include a reference timezone anyway.

Apple has their version. https://developer.apple.com/documentation/corefoundation/154...