changing time_t to an unsigned int would give another 68 years
But that would break backward compatibility with many applications. Few vendors have gone to an unsigned time_t (in fact, I don't know of any offhand) and there are good reasons for this.
A possibility would be to interpret the values in time zone files as unsigned WITHOUT changing the type of time_t. --ado
changing time_t to an unsigned int would give another 68 years
But that would break backward compatibility with many applications. Few vendors have gone to an unsigned time_t (in fact, I don't know of any offhand) and there are good reasons for this.
A possibility would be to interpret the values in time zone files as unsigned WITHOUT changing the type of time_t.
Wouldn't this prevent access to all the historical time data before 1970? In Paul's birthday example, we'd have no way of knowing what rules to apply when attempting to represent his birth date. Also, wouldn't this still require breaking compatibility with the existing file format? Applications or libraries would still need to recompile. While this approach might buy us another 68 years, it still only moves the bar up a certain amount. There's bound to be situations where people need to extrapolate dates into the future past whatever boundary we set. As long as we're looking at changing the file format, I'd opt for storing algorithmic data, perhaps using something like POSIX.1 strings as Paul suggested. - Tom
participants (2)
-
Olson, Arthur David -
Tom Peterson