FW: 32-bit 2038 issue

[Tom Peterson (USG)]

> > >    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