"Olson, Arthur David (NIH/NCI)" <olsona@dc37a.nci.nih.gov> writes:
Is using "%-4ld" to print the year a happy medium?
You mean, print something like "999 " for the year, with trailing spaces? Sorry, no, that doesn't conform either. If we're going to fail to conform to the standard, we shouldn't mess around with left-justification: it's even more confusing. I agree with Robert Elz that "that code is broken. End of story" is too harsh. That is why I'm advocating that we continue to have asctime always return a valid non-NULL string, even though the standard doesn't require this. This is a good thing -- we shouldn't gratuitiously break common usage even if it's no longer conforming. However, I'm not convinced by this example that it's worth departing from the standard here. Here's the example again: printf("The date is: %.24s today\n", asctime(tm)); This code does not work with arbitrary "tm" anyway, even on PDP-11 Unix Version 7 with 16-bit int and 32-bit timestamps. This is because the code will print garbage by truncating long years in some cases. There is no escaping this: asctime can't squish years past 9999 or before -999 into that string without either munging the traditional format (which will break other common usage) or printing the wrong year (which is simply incorrect). Since this example is already broken for years after 9999 or before -999, we needn't worry about the fact that conforming to the standard will also break this code for years in the range -99 through 999. If the example's "tm" was derived from a 32-bit time_t a la traditional Unix, there is no problem since the year will be at least 1901. And if "tm" was derived from a 64-bit time_t, or was constructed from arbitrary data, the code is already broken. So, let's just stick with the standard behavior (extended so that asctime never returns NULL). In practice, it won't break any applications that aren't already broken.