To: krb5-bugs@MIT.EDU
Subject: strftime formats in krb5_timestamp_to_sfstring
From: Ken Raeburn <raeburn@MIT.EDU>
Date: Thu, 19 Jan 2006 20:49:00 -0500
Message-Id: <tx1fynjoeib.fsf@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list
Sender: krb5-bugs-incoming-bounces@PCH.mit.edu
Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu
Content-Length: 1642

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