> Making the output of %s be implementation defined or unspecified > would be the same as the situation we're in now (where %s isn't in > the current standard at all) and so, what it produces if used is > simply unspecified.
But it would be documented as doing what it actually does, instead of being documented as printing a value that isn't there and can, at best, be only guessed at. If %s were documented as printing the number that would be obtained by calling mktime() on the struct tm? That would (a) be telling the actual truth, (b) would match existing implementations, and (c) would not mislead people into thinking it did something it doesn't (and, without ABI and possibly API changes, can't). I think the best change here is to bite the bullet and accept that the current interface, entrenched as it may be, is broken, either changing strftime and struct tm incompatibly or creating new strftime- and struct tm-alikes and abandoning strftime and struct tm to the same legacy status as the second arg to gettimeofday(). I think the best _likely_ change is to fix what %s is defined to print, and, preferably, do likewise for any other format specifiers which are similarly mis-described. >> No, there is no obligation to standardize incorrect behavior. > Of course not. But there is nothing incorrect here. I too think there is. At the barest minimum, the documentation is incorrect (it speaks of printing a number that isn't in the input struct and, as evidenced in this thread, can't be reliably obtained from that struct without undocumented assumptions). The design is broken. The right thing to do is to fix it, either with a flag day or by freezing the broken design, keeping it only for backward compatability, and creating a less-broken replacement. The latter has happened often enough before. (Examples are sigpause->sigsuspend or select->poll; the examples that come to mind are syscalls because they're what I use most. I have a fuzzy memory that there's one that has been through that twice, but I can't recall it now.) >> For my part, I had never had any idea you couldn't use strftime with >> gmtime() results, [...] > You can, mostly. Where is it documented what works and what doesn't? Those reading this thread now know that %s doesn't work in that case, but this thread hardly counts as documentation. What else doesn't work? Where is all that - heck, any of that - specified and documented? Until and unless it is, I maintain that dholland is right: you can't (reliably) use strftime with gmtime() - or anything else not returned directly from localtime() - because you're playing implementation roulette with whether the formats you think you want will do what you actually want. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
