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
