3 ms·

i32 is used for Unix time, resulting in overflow sometime in 2038. If that was changed to u32, overflow would happen instead in 2106. 15 years is close enough t

by uoaei 3y ago

i32 is used for Unix time, resulting in overflow sometime in 2038. If that was changed to u32, overflow would happen instead in 2106. 15 years is close enough that such a change would actually "make or break" timekeeping on human timescales. Using i64 for nanoseconds with the same origin (1970-01-01), we could cover roughly 1677-2262. Using u64 for nanoseconds we could cover roughly 1970-2554, or more generally about 585 years of timestamps from wherever a new proposed origin would be. Likely we don't need nanoscale precision for times far enough in the past, so I guess "far enough" is the definition worth arguing over here.

zamadatix 3y ago
You're looking far out for 2106 while ignoring the signing change already broke all date calculation from prior to the epoch. This means, with an unsigned version, you start out immediately butted against the problem that many real dates are not representable instead of running into this problem many years away. The advantage that future dates will be representable twice as far out doesn't make up for being butted up against the same problem in the other direction from the start. The same story is present with 64 bit nanosecond based timestamps, albeit we're keeping the mid date ever so slightly in the past for ease of conversion. If dates in 2264+ are important then just use a 128 bit timestamp, it'll fix the problem for many multiples the age of the universe instead of causing issues now to gain a few hundred years of padding in the future. Another common approach is to keep u64 second based timestamps and save the nanoseconds as another integer. This comes at the cost of "only" solving the problem for hundreds of billions of years but being interchangeable with those using non-fractional timestamps.
- evanelias 3y ago
  If we're really talking about timestamps, then by definition they only need to represent the current date and time. It's inherently a more limited use-case than general representation of arbitrary dates/times, as timestamps don't require the ability to store dates that occurred prior to the system's existence. For example, the unix epoch can safely be 1970 because the operating system did not exist prior to 1970, so there's no real-world situation in which you'd be time-stamping a system event or log entry prior to 1970. That said, time_t is usually a signed type in C. There are several reasonable historical explanations for that though, including the need to use -1 for an error return, and the fact that unsigned ints weren't present in C until 1978.
  - zamadatix 3y ago
    The danger comes when you need to compare your timestamps to something that may have happened before your system initialized. If you can both guarantee your time type will only ever be used for timestamps on your system and these will never in the future interact with or be compared to timestamps from prior to your system going online then you can get away with an epoch at the start of your system. The Unix epoch was never an issue being 1970 because they knew they were making it as signed, not because they thought Unix systems would never deal with e.g. files from before Unix was created.
    - evanelias 3y ago
      Again, unsigned ints weren't even present in C until 1978, so of course it was signed -- there was no alternative. As far as I've ever read, negative unix timestamp values generally were not used. Since -1 was used as an error value, you cannot safely determine whether that value represents an error vs a legitimate timestamp one second before the epoch. I'm not familiar with if/how early versions of Unix were able to interact with non-Unix files/filesystems, but I doubt they would preserve metadata such as mtime if so.

by uoaei 3y ago

zamadatix 3y ago

You're looking far out for 2106 while ignoring the signing change already broke all date calculation from prior to the epoch. This means, with an unsigned version, you start out immediately butted against the problem that many real dates are not representable instead of running into this problem many years away. The advantage that future dates will be representable twice as far out doesn't make up for being butted up against the same problem in the other direction from the start. The same story is present with 64 bit nanosecond based timestamps, albeit we're keeping the mid date ever so slightly in the past for ease of conversion. If dates in 2264+ are important then just use a 128 bit timestamp, it'll fix the problem for many multiples the age of the universe instead of causing issues now to gain a few hundred years of padding in the future. Another common approach is to keep u64 second based timestamps and save the nanoseconds as another integer. This comes at the cost of "only" solving the problem for hundreds of billions of years but being interchangeable with those using non-fractional timestamps.

evanelias 3y ago
If we're really talking about timestamps, then by definition they only need to represent the current date and time. It's inherently a more limited use-case than general representation of arbitrary dates/times, as timestamps don't require the ability to store dates that occurred prior to the system's existence. For example, the unix epoch can safely be 1970 because the operating system did not exist prior to 1970, so there's no real-world situation in which you'd be time-stamping a system event or log entry prior to 1970. That said, time_t is usually a signed type in C. There are several reasonable historical explanations for that though, including the need to use -1 for an error return, and the fact that unsigned ints weren't present in C until 1978.
- zamadatix 3y ago
  The danger comes when you need to compare your timestamps to something that may have happened before your system initialized. If you can both guarantee your time type will only ever be used for timestamps on your system and these will never in the future interact with or be compared to timestamps from prior to your system going online then you can get away with an epoch at the start of your system. The Unix epoch was never an issue being 1970 because they knew they were making it as signed, not because they thought Unix systems would never deal with e.g. files from before Unix was created.
  - evanelias 3y ago
    Again, unsigned ints weren't even present in C until 1978, so of course it was signed -- there was no alternative. As far as I've ever read, negative unix timestamp values generally were not used. Since -1 was used as an error value, you cannot safely determine whether that value represents an error vs a legitimate timestamp one second before the epoch. I'm not familiar with if/how early versions of Unix were able to interact with non-Unix files/filesystems, but I doubt they would preserve metadata such as mtime if so.