(Sorry for the cross-post; original was in netbsd-help, but I thought that
the Y2K issues were relavant to tech-misc.)


(Below, tests and sources are w.r.t. 1.4's tar.  YMMV.)

Looking at the source, it appears to accept a fairly wide range.  E.g.
(from a comment in the get_date.y file):

  /* ISO 8601 format.  yyyy-mm-dd. */

(The -N option calls on get_date().  get_date(), in turn, is generated
in part from a grammar in get_date.y.  See /usr/src/gnu/usr.bin/tar/tar.c
and /usr/src/gnu/usr.bin/tar/get_date.y.)


That's the good news.  The bad news is that it seems to be at least partly
broken.  Some forms work, e.g.:

 tar -N today -cvf - . | wc
 tar -N yesterday -cvf - . | wc
 tar -N '10 days ago' -cvf - . | wc
 tar -N 'January 1, 98' -cvf - . | wc
 tar -N 1998-01-01 -cvf - . | wc

...on the other hand, these fail:

 tar -N 'January 1, 00' -cvf - . | wc
 tar -N 'January 1, 2000' -cvf - . | wc
 tar -N 2000-01-01 -cvf - . | wc


(Note that (some?) relative dates seem to work.  You might try pre-Y2K
dates for some of the formats that you tried before, though it may not be
very helpful beyond seeing how the date may be specified, in theory.)

I wonder if perhaps the -N option is too fancy?  Why not pick a format
(say the ISO format, or something close to it) and insist upon that?  Or
does POSIX require this comlex date handling?


Possibly not the whole story, but certainly suspicous-looking, is this
line from getdate.y::Convert():

    if (Year < EPOCH || Year > 1999

I can understand the lower-bound---but where did the 1999 upperbound come
from?  And, with all the trouble to produce a correct grammer, it is
striking that they didn't at least push the limit of a 32-bit count of
seconds since {EPOCH}.

The striking peculiarity of this code makes me think that there may be a
good reason for it.  But...it could have to do with the target systems
that GNU tar has to run on, and not have any merit for us.

That line is the only occurance of the constant 1999, and the constant
2000 doesn't appear, so bumping it up to---what, 2038? 2037?---might work.

I haven't tried any changes to this, since I don't expect that it was
simple brain-damage that put a 1999 cap on the {year}.  If it wasn't
brain-damage, then can anyone explain why it's the way that it is?
Can someone commit a fix (or has it already been fixed in -current)?


  "I probably don't know what I'm talking about."  --rkr@rkr.kcnet.com