5 ms·

"...re-define time_t as an unsigned integer instead of a signed integer...This doubles the range of numbers it can store." I don't think that's how it works...

allenbrunson 18y ago
it would double the range of positive integers it can store. that would mean no more "cheating," and using negative values to represent times before 1970. personally i think they should redefine time_t to be a signed 64-bit integer. a better solution, i think.
- likpok 18y ago
  IIRC 64-bit Linux does this. As 64-bit becomes more prevalent, this may become a non-issue (Windows 7 was supposedly going to be 64-bit only, and one of the next releases may make this true). 16-bit Windows only lasted 10 years. There is 30 years until the problem. The biggest issue will be embedded code, but much of that may have failed/been replaced when 2038 rolls around.
  - eru 18y ago
    And most embedded code does not care about dates anyway.
- deleted 18y ago
  [deleted]
- sh1mmer 18y ago
  Isn't the real problem recompiling executables for which the source is lost or are so hopelessly mired in legacy production systems deploying them would be hell on earth. That was the basic problem with Y2K no one expected them to live that long so upgrading them wasn't considered. This seems like the same retrofit issue, possibly with more warning and experience second time around.
extension 18y ago
Actually, it wouldn't change anything since add/sub are the same for signed (2s comp) and unsigned ints and C will happily let you assign a signed literal to an unsigned variable. You would just get some compiler warnings and maybe break the rare piece of code that multiplies negative time deltas. What you have to fix are the operations that convert between time_t and some other representation and those are not going care about the data type.

5 ms·

"...re-define time_t as an unsigned integer instead of a signed integer...This doubles the range of numbers it can store." I don't think that's how it works...

by latortuga 18y ago

allenbrunson 18y ago
it would double the range of positive integers it can store. that would mean no more "cheating," and using negative values to represent times before 1970. personally i think they should redefine time_t to be a signed 64-bit integer. a better solution, i think.
- likpok 18y ago
  IIRC 64-bit Linux does this. As 64-bit becomes more prevalent, this may become a non-issue (Windows 7 was supposedly going to be 64-bit only, and one of the next releases may make this true). 16-bit Windows only lasted 10 years. There is 30 years until the problem. The biggest issue will be embedded code, but much of that may have failed/been replaced when 2038 rolls around.
  - eru 18y ago
    And most embedded code does not care about dates anyway.
- deleted 18y ago
  [deleted]
- sh1mmer 18y ago
  Isn't the real problem recompiling executables for which the source is lost or are so hopelessly mired in legacy production systems deploying them would be hell on earth. That was the basic problem with Y2K no one expected them to live that long so upgrading them wasn't considered. This seems like the same retrofit issue, possibly with more warning and experience second time around.
extension 18y ago
Actually, it wouldn't change anything since add/sub are the same for signed (2s comp) and unsigned ints and C will happily let you assign a signed literal to an unsigned variable. You would just get some compiler warnings and maybe break the rare piece of code that multiplies negative time deltas. What you have to fix are the operations that convert between time_t and some other representation and those are not going care about the data type.