32-bit 2038 issue

[Joel Tornatore]

changing time_t to an unsigned int would give another
68 years without any of the size/performance problems
mentioned in Tom's email.

joel


##  From tomp at zk3.dec.com Tue Nov 11 12:40:27 1997
##  Old-Return-Path: <tomp at zk3.dec.com>
##  To: tz at elsie.nci.nih.gov
##  Cc: Tom Peterson <tomp at zk3.dec.com>, simons at zk3.dec.com, dlong at zk3.dec.com
##  Subject: 32-bit 2038 issue
##  X-Mts: smtp
##  
##  
##  Has anyone considered what to do about time zone files and the 32-bit 2038 
##  issue?  This comment from zic.c sums up the problem:
##  
##  > /*
##  > ** The tz file format currently allows at most 32-bit quantities.
##  > ** This restriction should be removed before signed 32-bit values
##  > ** wrap around in 2038, but unfortunately this will require a
##  > ** change to the tz file format.
##  > */
##  
##  With Y2K bringing attention to time-related problems, there's an increasing 
##  awareness/concern about the 2038 issue as well.  People know it's not just a 
##  system clock setting issue.  The limitations affect projected dates used by 
##  applications as well.  Problems are already cropping up where financial 
##  institutions can't generate amortization data for 40, 50, etc year loans and 
##  the like.  I expect there are other practical examples as well.
##  
##  As new 64-bit UNIX platforms are emerging, there's a trend toward 64-bit 
##  time_t's.  While this certainly eliminates the 2038 limit, it also creates a 
##  problem for time zone data files.  A time zone file filled with data spanning 
##  64-bits of seconds-based time would be huge, not to mention the performance 
##  problems of accessing it.  Some ideas for addressing this problem are:
##  
##  1) Expand the date/time boundaries for time zone files to a specific range.  
##  This would have to balance file size vs anticipated application needs.  
##  Perhaps an upper limit corresponding to the year 2100 or 2200 would suffice?  
##  Regardless of the range set, this approach only delays the problem.
##  
##  2) Find some way to mimic what the zic compiler does at run-time.  This might 
##  involve generating some kind of algorithmic data for each time zone which can 
##  be used to calculate future transition times, etc on-the-fly.  I'm not sure 
##  this is possible or practical given the varied complexity of time zone rules.
##  
##  3) Other ideas???
##  
##  Also, with 64-bit time_t's, the tm struct becomes the limiting factor.  
##  Boundary checks now become an issue for localtime()/gmtime() instead of 
##  mktime().  This is a problem for standards at a mininum.  While mktime() has 
##  the (somewhat ambiguous) -1 return value for non-representable times, no such 
##  provision is defined for localtime()/gmtime().
##  
##  Any ideas or precedent for addressing this issue?
##  
##  thanks,
##  - Tom
##  
##  =====================================================================
##  Tom Peterson                   | DIGITAL UNIX Development Environment
##  Digital Equipment Corporation  | Phone: (603) 884-7550
##  110 Spit Brook Road ZKO3-2/W17 | FAX:   (603) 884-2257
##  Nashua, NH 03062-2698          | Email: mailto:tomp at zk3.dec.com
##  
##  
##