heads-up: parsedate() changes

[Robert Elz <kre%munnari.OZ.AU@localhost>]

If you have or know of code that uses parsedate(3), or anything which
uses it (like date -d, or touch -d) please beware of some changes.

From now on, 2 digit years from 69-99 (was 70-99) are treated as
20th century (19yy) and values 00-68 (was 00-69) are treated as 21st
century (20yy).   This complies with posix, and allows 2 digit local
time representations of the epoch (and times near it) to be correctly
processed in timezones west of greenwich.

Also, a leading (POSIX defined subset of an) ISO-8601 timestamp,
that is yyyy-mm-ddTHH:SS:MM[radix&fraction][Z] is now handled when
the 'T' is literally a 'T' (or 't') rather that a space (which is also
correct, and was previously handled).  This format (with the 'T') which
previously wasn't handled by parsedate works only when it occurs at the
very beginning of the input string (not even any preceding whitespace).
This is sufficient for us to conform to POSIX in the places where this
is defined to be acceptable input (that is, for "touch -d").

All other existing parsedate inputs which used to work should continue
to work as before, and some that failed before (like using a ',' as the
radix character before the meaningless fractional seconds - meaningless
because parsedate() returns a time_t which only holds whole seconds).

But watch for any deviations to what is expected, and let me know if
you see anything.

kre