Ticket History #3359: strftime formats in krb5_timestamp_to_sfstring

The strftime formats tried by this function, in order, are:

"%c", /* Default locale-dependent date and time */
"%d %b %Y %T", /* dd mon yyyy hh:mm:ss */
"%x %X", /* locale-dependent short format */
"%d/%m/%Y %R" /* dd/mm/yyyy hh:mm */

If they all fail, we then try:

sprintf(buffer, "%02d/%02d/%4d %02d:%02d",
tmp->tm_mday, tmp->tm_mon+1, 1900+tmp->tm_year,
tmp->tm_hour, tmp->tm_min);

which agrees with the last strftime format, at least.

Bug #1: We don't test for localtime(_r) failing. Granted, failure of
that function seems pretty unlikely, but some email I've gotten from
Lenny Foner shows he's got a weird situation where klist shows all the
times as "01/00/00 00:00:00", which would be explained by localtime
failing and a block of zeros readable at address 0 (NULL) (or by
localtime_r filling in zeros, or localtime_r not doing anything and
the stack slots containing zeros). With the recent leap second,
there's probably been a lot of timezone-data tweaking lately.

Bug #1a: Check the callers of krb5_timestamp_to_sfstring and make sure
they check for errors, too. It looks like on a returned error, klist
will simply fail to print anything out, instead of printing a broken
string.

Bug #2: The day/month/year format is ambiguous, and arguably wrong for
US users. I'd suggest we go with ISO 8601 and RFC 3339
recommendations, specifically "yyyy-mm-dd HH:MM[:SS]", with either
space or "T" separating the date and time. (I doubt we want the time
zone data reported.)

Also, check the various standards and other specs: Is %c always
supported? Is there any reason for so many fallbacks?

Ken