Description Shawn Pearce 2010-07-07 11:10:22 EDT

JGit contains a number of bugs that will arise in the year 2038, caused by the 32 bit second based timestamp rolling over at Jan 19, 2038, 03:14:07 AM GMT.

This bug tracks the location of these 2038 issues.  For various reasons, they aren't likely to be fixed before 2020.


DirCache/DirCacheEntry:

  The smudge racily clean algorithm sets the file's cached modification
  time forward to Jan 19, 2038, 03:14:07 AM GMT.  We depend upon this
  magical value never appearing as an actual File.lastModified() result.
  We need to use a different value or a different smudge algorithm as we
  get closer to 2038.

  The mtime field in the 'DIRC' file is only 4 bytes wide, and is used
  as a signed int.  In 2038 this field will roll over on us and start
  to report negative values.  The file format needs to change, or the
  Git community needs to declare that times prior to Jan 1 1970 aren't
  relevant in the index, permitting this field to be treated as unsigned.


RevCommit.getCommitTime():

  The commit time in a RevCommit is stored as a 32 bit signed int, as
  seconds since the UNIX epoch.  This time is used to sort commits by
  commit date in the priority queue.  Because we need to juggle many
  instances in memory at once, the smaller int storage was chosen as a
  memory and performance optimization.

  Moving from 1 second intervals to 2 second intervals would extend the
  lifespan of this field from 2038 until 2106.  Callers may be impacted
  by the loss of resolution, so the scope of that should be looked at
  before making the change.